Здравствуйте, AlexNek, Вы писали:

У меня к тебе пара вопросов.

AN>>>Вот буквально сегодня нашел проблемку в проекте. Захотел шеф классы на диаграмме разкрасить по принадлежности к под-проектам.

ГВ>>Это, наверное, был очень большой шеф, которому понадобилось сделать презентацию инвесторам.
AN>Все абсолютно наоборот Шеф "маленький" диаграмма для внутреннего использования.

Для какого именно использования?

ГВ>> А инвесторы — не иначе, как программисты со стажем, у которых мозги ещё не проветрились после вакханалии ООП. Иначе я с очень большим трудом понимаю, на кой такие художества — заняться больше нечем?
AN>В данном конкретном случае, смысл есть. Есть классы принадлежащие конкретной области 1, есть принадлежащие области 2 и есть еще общие классы на которых базируется 1 и 2. (Ну упрощенно немного). И сразу по цвету, ничего не описывая и говоря можно например сказать, что эти классы принадлежат исключительно области 1. Поэтому делая изменения в этой области, нет риска затронуть остальные области. А если будут изменения в общей области, то нужно обязательно планировать тестирование и 1 и 2.

А у вас, что, нет подобных описаний в словесном виде?

AN>>>В данном случае, для диаграммы классов, были выбраны строго определенные классы, которые могут принадлежать только к одному из 4-х под-проектов. Получилось листов 10. И вот смотрю на одном листое как — то "некрасиво", цвет базового класса не такой как у всех, а на другом есть базовый класс без наследников. Начал рыть дальше. Оказалось что в двух проектах есть классы с одинаковыми именами. Один, в правильном месте, уже не используется. Другой, который используется должен, по идее быть в другом месте. В принципе мелочь, но нежелательно, "портить красоту". Нужно хотя бы неиспользуемый убрать, а то может ерунда получится.

ГВ>>Такими примерами ты дискредитируешь саму идею построения диаграмм. Ну, не используемый класс, ну, в другом месте, да он там ещё сто лет никому нужен бы не был
AN>Любая зазубринка на шестеренке когда либо может вылезти боком, поэтому увидев зазубринку можно ее либо записать в реестр зазубринок, либо исправить.

Ты не находишь, что в этом и предыдущем твоём абзаце слишком много "можно" и ни одного "нужно"?

AN>Вот кстати, еще недавний пример. Где то год назад было решено переимовать одну ДЛЛ-ку (всего-то в конце "s" убрать). Namespace за неимением тогда времени решили оставить как есть, фигня ведь мелочь. А в один прекрасный день, в одном из проектов перестали грузится ресурсы. В итоге оказалось, что некто сделал "правильное" имя без "s". Ладно, исправили все как нужно, но теперь система CI отказалась бильдить проект, так как один из тестеров нацепил дополнительные тесты, а сам оказался в это время в отпуске. Не подсчитывал специально, но время исправления той "мелочи" было бы точно гораздо меньше исправления последствий.
AN>Ладно, можно было оставить это класс мертвяком. Но обязательно когда — то кто-то найдется, кто захочет его использовать. Так зачем доводить до этого, когда проще убрать его сейчас. Специально это обычно не ищется, но если что попутно замечаешь, лучше не игнорировать.

То есть штатного code review у вас нет?

ГВ>>, ан нет, вот понадобилось шефу малярное искусство... Зазеркалье какое-то, право слово.
AN>А что стоит то выделить нужные классы и изменить им цвет, да практически ничего. А польза есть.

Это стоит очень много, если учесть необходимость покупки Розы. Плюс потери времени, плюс ещё много чего.

AN>Да если кто еще плакат МФС помнит — там тоже классы были цветными, весьма удобно.

Ни фига оно не удобно — всё равно названия классов читать приходится.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, AlexNek, Вы писали:

ГВ>У меня к тебе пара вопросов.

AN>>>>Вот буквально сегодня нашел проблемку в проекте. Захотел шеф классы на диаграмме разкрасить по принадлежности к под-проектам.

ГВ>>>Это, наверное, был очень большой шеф, которому понадобилось сделать презентацию инвесторам.
AN>>Все абсолютно наоборот Шеф "маленький" диаграмма для внутреннего использования.

ГВ>Для какого именно использования?
В том смысле, что не для презентации. Части покидал в документацию.

ГВ>>> А инвесторы — не иначе, как программисты со стажем, у которых мозги ещё не проветрились после вакханалии ООП. Иначе я с очень большим трудом понимаю, на кой такие художества — заняться больше нечем?
AN>>В данном конкретном случае, смысл есть. Есть классы принадлежащие конкретной области 1, есть принадлежащие области 2 и есть еще общие классы на которых базируется 1 и 2. (Ну упрощенно немного). И сразу по цвету, ничего не описывая и говоря можно например сказать, что эти классы принадлежат исключительно области 1. Поэтому делая изменения в этой области, нет риска затронуть остальные области. А если будут изменения в общей области, то нужно обязательно планировать тестирование и 1 и 2.

ГВ>А у вас, что, нет подобных описаний в словесном виде?
Это же читать нужно и не так подробно, а тут глянул и все.

AN>>>>В данном случае, для диаграммы классов, были выбраны строго определенные классы, которые могут принадлежать только к одному из 4-х под-проектов. Получилось листов 10. И вот смотрю на одном листое как — то "некрасиво", цвет базового класса не такой как у всех, а на другом есть базовый класс без наследников. Начал рыть дальше. Оказалось что в двух проектах есть классы с одинаковыми именами. Один, в правильном месте, уже не используется. Другой, который используется должен, по идее быть в другом месте. В принципе мелочь, но нежелательно, "портить красоту". Нужно хотя бы неиспользуемый убрать, а то может ерунда получится.

ГВ>>>Такими примерами ты дискредитируешь саму идею построения диаграмм. Ну, не используемый класс, ну, в другом месте, да он там ещё сто лет никому нужен бы не был
AN>>Любая зазубринка на шестеренке когда либо может вылезти боком, поэтому увидев зазубринку можно ее либо записать в реестр зазубринок, либо исправить.

ГВ>Ты не находишь, что в этом и предыдущем твоём абзаце слишком много "можно" и ни одного "нужно"?
"Нужно хотя бы неиспользуемый убрать"

AN>>Вот кстати, еще недавний пример. Где то год назад было решено переимовать одну ДЛЛ-ку (всего-то в конце "s" убрать). Namespace за неимением тогда времени решили оставить как есть, фигня ведь мелочь. А в один прекрасный день, в одном из проектов перестали грузится ресурсы. В итоге оказалось, что некто сделал "правильное" имя без "s". Ладно, исправили все как нужно, но теперь система CI отказалась бильдить проект, так как один из тестеров нацепил дополнительные тесты, а сам оказался в это время в отпуске. Не подсчитывал специально, но время исправления той "мелочи" было бы точно гораздо меньше исправления последствий.
AN>>Ладно, можно было оставить это класс мертвяком. Но обязательно когда — то кто-то найдется, кто захочет его использовать. Так зачем доводить до этого, когда проще убрать его сейчас. Специально это обычно не ищется, но если что попутно замечаешь, лучше не игнорировать.

ГВ>То есть штатного code review у вас нет?
В этом проекте специально выделенного человека нет. А если бы и был, то он бы это не нашел.
А когда был, приходило что то типа "в файле хх, имя переменнай аа не соответвует п.4.1.1"

ГВ>>>, ан нет, вот понадобилось шефу малярное искусство... Зазеркалье какое-то, право слово.
AN>>А что стоит то выделить нужные классы и изменить им цвет, да практически ничего. А польза есть.

ГВ>Это стоит очень много, если учесть необходимость покупки Розы.
А кто говорил о Розе? Жалко значка подходящего нет.

ГВ>Плюс потери времени, плюс ещё много чего.
По сравнению с "построением" диаграммы это практически ничего, сколько нужно для выбора некоторого количества квадратиков.
А что еще?

AN>>Да если кто еще плакат МФС помнит — там тоже классы были цветными, весьма удобно.

ГВ>Ни фига оно не удобно — всё равно названия классов читать приходится.
Названия читаются уже потом, а вначале читается "концепт" цветом.
Цвет добавляет как бы 3-е измерение. Представьте "архитектора 2010" без цвета.

Я ведь никого не заставляю так делать, кому то это нравится, а кто то считает это совершенно бесполезным. У каждого будет свое личное мнение. И если есть два разных мнения совсем не обязательно, что одно из них правильное, а другое нет.

Здравствуйте, SkyDance, Вы писали:

D>>Как я себе это вижу:
D>>1. UML по исходникам
D>>2. Понимание архитектуры и её поверхностное документирование
D>>3. Закрепить за 3 людьми определенные области в этой архитектуре
D>>4. Люди пишут Unit Test'ы, выполняют текущие задачи по исправлению ошибок, проводят в свободное время рефакторинг

SD>Как это будет в реальности:
SD>1. Вот из-за того бага все наши клиенты застопорились, фиксите срочно!
SD>2. Сами говорили, архитектура плохая, вот и не трогайте ничего, никакого "полного рефакторинга" и прочих разрушительных для проектов вида "карточный домик" вещей.
SD>3. Никого никто крепить не будет, если архитектуры нет, значит, ее нет.
SD>4. А вот с тестами — это категорически правильно!!! Только не юнит, а вообще — тесты, тесты, тесты, тесты! Как тов. С. Балмер в знаменитом клипе "Developers, developers".
+100
Насчет тестов тут согласен.

SD>Исходя из опыта и реальности — забудьте про красивые слова "архитектура", UML, "документировать". У вас же не забрали право консультироваться с изначальными разработчиками? Вот и пробуйте при заходе в тупик совершать "звонок другу" с конкретными вопросами "а почему вот там сделано вот так".
Какому еще другу
Незнакомому человеку, который уволился за год, до того как ты начал работать в компании?
А в настоящее время никто — ни коллеги ни руководство — не знают даже где он (в какой стране живет)...

SD>И — тесты, тесты, тесты. Чем быстрее вы автоматизируете тестирование, тем проще вам будет вносить изменения, не нарушающие стабильную работу системы (это самое сложное для проектов с 10-летним легаси).

Здравствуйте, AlexNek, Вы писали:

AN>А кто говорил о Розе? Жалко значка подходящего нет.
Ты про етот? ( :: wow :: ) дарю!