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

G>>А ты ответил на какой-то другой, одному тебе известный вопрос. Мне очень жаль, Ллойд. Но так как это явление систематическое, я с тобой обычно всерьез и не беседую.

L>А ты постарайся, Gaperton, и подумай. Не пиши, не играй на эмоциях, не переходи на личности, не оскорбляй собеседника, а просто сядь и в спокойной обстановке подумай. Тогда наверняка поймешь, в чем именно польза.

Давай поступим проще. Давай я буду людей спрашивать, они мне будут отвечать, а ты не будешь мне мешать с людьми беседовать? А если уж встреваешь, то будешь читать, о чем разговор идет? Это такая невыполнимая просьба, Ллойд?

L>Твое истеричное хамство мне уже надоело, куда только смотрят модераторы?

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

И я не понимаю, какого черта ты ко мне из раза в раз назойливо пристаешь. Ты видишь где-то здесь "истерическое хамство"? Жалуйся модераторам.

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

G>>Даже если ты будешь пытаться по детски брать меня "на слабо". Реально, слабо, ибо зело скучно. Трата времени.

L>Тебе слабо не потому что скучно, а потому что сказать тебе нечего. Иначе бы ответил "по существу вопроса" и не разводил бы эту "трату времени" на два десятка постов.

Ллойд, мне не интересно обсуждать ни твою, ни свою личность. Не вижу в этом никакого интересного "существа вопроса".

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

G>>>А ты ответил на какой-то другой, одному тебе известный вопрос. Мне очень жаль, Ллойд. Но так как это явление систематическое, я с тобой обычно всерьез и не беседую.

L>>А ты постарайся, Gaperton, и подумай. Не пиши, не играй на эмоциях, не переходи на личности, не оскорбляй собеседника, а просто сядь и в спокойной обстановке подумай. Тогда наверняка поймешь, в чем именно польза.

G>Давай поступим проще. Давай я буду людей спрашивать, они мне будут отвечать, а ты не будешь мне мешать с людьми беседовать? А если уж встреваешь, то будешь читать, о чем разговор идет? Это такая невыполнимая просьба, Ллойд?

Не, Gaperton, не так не пойдет. Мне тогда и тебя придется попросить поступать так же, а я знаю, что это не в твоих силах.

G>И я не понимаю, какого черта ты ко мне из раза в раз назойливо пристаешь.

А я не к тебе пристаю, а к тем, кто пишет что-то, что звучит мягко говоря сомнительно. Так уж получилось, что я не согласен с твоим утверждение о не нужности диаграмм, потому и "пристал".
Когда ты пишешь что-то, что вполне вяжется с моими представленими, я не пристаю.

G>Ты видишь где-то здесь "истерическое хамство"? Жалуйся модераторам.

И что они сделают? Забанят? Нафик такое счастье, я себе не враг, ты и полезного много пишешь.

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

G>>>Даже если ты будешь пытаться по детски брать меня "на слабо". Реально, слабо, ибо зело скучно. Трата времени.

L>>Тебе слабо не потому что скучно, а потому что сказать тебе нечего. Иначе бы ответил "по существу вопроса" и не разводил бы эту "трату времени" на два десятка постов.

G>Ллойд, мне не интересно обсуждать ни твою, ни свою личность. Не вижу в этом никакого интересного "существа вопроса".

Gaperton, так зачем же ты раз за разом переводишь разговор не обсуждение личности, если тебе не интересно?

TSP>А откуда уверенность, что пользователи знают, чего они хотят?
а где я писал что они знают чего хотят?

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

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

G>>>Небольшая поправка. С теми, кто говорит что пробовал и помогает. Очевидно, также ничего делать не надо. "Ты тоже говори" (с).
AN>>Ну я не собираюсь никого ни в чем убеждать Если вы считаете мои высказывания плодом больного воображения — это Ваше право.

G>Нет, "плодом больного воображения" я их не считаю. Я не Lloyd, эмоциональных оценок чужим высказываниям не выдаю.
Уже приятно, но я воспринял данное высказывание где то в этом ключе.
AN>>>>Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.

G>>>И в чем состоит польза?
AN>>Если в диаграмме нет порядка, то и в проекте и в коде он также отсутствует либо там просто "не пахнет классовым подходм". По крайней мере, это рабочая гипотеза которую можно подтвердить или опровернуть.

G>1) В любом большом "проекте" с длинной историей вы не обнаружите никакого видимого "порядка" в автогенерированной диаграмме. На то есть объективные причины. Это будет означать лишь то, что вы в ней ничего не понимаете.
Вообще то для любого большого проекта в автогененрированной диаграмме практически ничего нельзя увидеть. Речь идет о "приготовленной" диаграмме и самом процессе "приготовления".
G>2) Сама "рабочая гипотеза" об "отсутствии порядка" субъективна и практически бесполезна.
Только из-за того что само понятие порядка субъективно, помните задачи — найди недостающую фигуру/предмет?
Если нет описания "правил порядка", то и решить задачу невозможно. Поэтому для себя я ввел понятие "красоты". Объяснить его довольно таки затруднительно, но если диаграмму нельзя привести к "красивому виду", то 100% с проектом что то не в порядке. Иначе говоря, "процент полезности" довольно высок.
G>Из ее "верности" или "неверности" напрямую не следует никаких полезных действий.
Хотя бы для понимания проекта это требуется. Я могу видеть участки которые "мешают сделать красоту" и сосредоточить внимание именно на них, что бы разобраться почему именно так сделано.
G>А понимание в инженерном деле требуется для действия.
Это смотря от поставленнй задачи. Но в любом случает требуется вначале понять/знать как эта фигня работает. И как правило, при этом требуется комплексный подход.
G>И если первым действием будет являться "наведение порядка" в коде, в котором вы плохо разбираетесь, святая обязанность менеджера немедленно дать таким инициативным людям по рукам.
Никто об этом не говорил, что нужно наводить порядок, так как даже в своем проекте не всегда следует это делать.
Тут где — то аналогия с покупкой поддержанной машины. Ведь мы же не лезем сразу в мотор. Для начала достаточно бегло взлянуть на корпус, а затем может быть детальный внешний осмотр с проверкой функционирования. И тут же составляется план действий: передние колеса заменить, найти отчего не включается правый задний поворотник (может лампочка сгорела?), салон почистить и пр.

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

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

G>>>Пример такой "проблемы", пожалуйста. Жуть как любопытно.
AN>>На диаграмме это связи Janus-Model и PropertyGridCustomizer, TreeGrid. В данном случае они мне непонятны и уменьшают "красоту".

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

AN>В принципе мелочь, но нежелательно, "портить красоту".

Мда, с такими рассуждениями, на месте менеджера я бы задумался, чем это мои люди занимаются.

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

AN>Если нет описания "правил порядка", то и решить задачу невозможно. Поэтому для себя я ввел понятие "красоты". Объяснить его довольно таки затруднительно, но если диаграмму нельзя привести к "красивому виду", то 100% с проектом что то не в порядке. Иначе говоря, "процент полезности" довольно высок.

Полезность понимания определяется полезными действиями, которые можно предпринять, имея это понимание. Нет полезных действий — нет пользы. Об этом сказано в следующем же предложении.

G>>Из ее "верности" или "неверности" напрямую не следует никаких полезных действий.
AN>Хотя бы для понимания проекта это требуется. Я могу видеть участки которые "мешают сделать красоту" и сосредоточить внимание именно на них, что бы разобраться почему именно так сделано.

Понимание требуется для действия, и этим будущим действием должно направляться. Нет смысла его сосредотачивать на "красоте" или других не относящихся к действию вещах. Впрочем, об этом опять говорится в следующем же предложении.

Раздербанивая ответ на отдельные предложения, и отвечая подстрочником, вы лишаете себя возможности понять мысль исходного поста. Единица мысли в русском языке — абзац, а не предложение. Отвечать надо на мысль, а не на слова.

G>>А понимание в инженерном деле требуется для действия.
AN>Это смотря от поставленнй задачи.

Всегда. "Задача" всегда подразумевает выполнение полезного действия с полезным результатом. То есть, если нет действий, которое вам надо выполнить с программой — вам вообще нет нужды в ней разбираться. Незачем. Нефиг лезть в работающий механизм.

AN>Но в любом случает требуется вначале понять/знать как эта фигня работает. И как правило, при этом требуется комплексный подход.

G>>И если первым действием будет являться "наведение порядка" в коде, в котором вы плохо разбираетесь, святая обязанность менеджера немедленно дать таким инициативным людям по рукам.
AN>Никто об этом не говорил, что нужно наводить порядок, так как даже в своем проекте не всегда следует это делать.

Рефакторинг из соображений красоты был единственным действием, для которого требуется ваше понимание. Раз вы его выполнять не собираетесь, ваше "понимание", движимое абстрактной красотой, не приводит вообще ни к каким действиям, и, таким образом, получается бесполезно. Что и требовалось доказать.

AN>Тут где — то аналогия с покупкой поддержанной машины. Ведь мы же не лезем сразу в мотор. Для начала достаточно бегло взлянуть на корпус, а затем может быть детальный внешний осмотр с проверкой функционирования. И тут же составляется план действий: передние колеса заменить, найти отчего не включается правый задний поворотник (может лампочка сгорела?), салон почистить и пр.

Правильная аналогия — вам достались чертежи неизвестной модели автомобиля (это ваши исходники), в которые вам надо вносить изменения по рекламациям (это задача поддержки, в контексте которой ваша оценка красоты обводов кузова никому не интересна). Ваша аналогия — неправильная.

В разработке ПО вы, думаю, как и я — разбираетесь получше, чем в конструировании и производстве автомобилей. Давайте без "бытовых" аналогий уровня домохозяек обойдемся.

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

AN>>В принципе мелочь, но нежелательно, "портить красоту".

SD>Мда, с такими рассуждениями, на месте менеджера я бы задумался, чем это мои люди занимаются.

Менеджер для этого слишком занят. Он одну диаграмму на десяти (!) листах в цвета красит. Для лучшего понимания системы, очевидно. Правило 7+-2 сущности на лист — это для слабаков.

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

AN>>В принципе мелочь, но нежелательно, "портить красоту".

SD>Мда, с такими рассуждениями, на месте менеджера я бы задумался, чем это мои люди занимаются.
Занимаются обнаружением проблем в проекте. Почти любая недокументированная "некрасивость" рано или поздно вылезет каким то боком. А документированная только говорит о том, что да мы знаем — это сделано плохо/неправильно, но другого решения у нас пока нет.
Кстати, происходит это как бы между прочим, при решении других задач.

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

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

AN>>Если нет описания "правил порядка", то и решить задачу невозможно. Поэтому для себя я ввел понятие "красоты". Объяснить его довольно таки затруднительно, но если диаграмму нельзя привести к "красивому виду", то 100% с проектом что то не в порядке. Иначе говоря, "процент полезности" довольно высок.

G>Полезность понимания определяется полезными действиями, которые можно предпринять, имея это понимание. Нет полезных действий — нет пользы.
А что без знания полезных действий не нужно ничего понимать? Нафига нужно было пытаться что то понимать аж целых 15 лет (10+5) не имеея никакого представления о конкретных действиях.

G>>>Из ее "верности" или "неверности" напрямую не следует никаких полезных действий.
AN>>Хотя бы для понимания проекта это требуется. Я могу видеть участки которые "мешают сделать красоту" и сосредоточить внимание именно на них, что бы разобраться почему именно так сделано.

G>Понимание требуется для действия, и этим будущим действием должно направляться. Нет смысла его сосредотачивать на "красоте" или других не относящихся к действию вещах. Впрочем, об этом опять говорится в следующем же предложении.
Если я читаю книгу и хочу понять ее, для каких действий мне это нужно?
Отчего при начале работы часто дают задание "разобраться с проектом", но при это не говорят абсолютно точно, что нужно делать. Да и кто может знать что в процессе работы с ним прийдется делать?

G>Раздербанивая ответ на отдельные предложения, и отвечая подстрочником, вы лишаете себя возможности понять мысль исходного поста. Единица мысли в русском языке — абзац, а не предложение. Отвечать надо на мысль, а не на слова.
Что то я сильно слаб в лингвистике, можно ссылочку на определение Да и с ловлей "верных" мыслей я тоже как то не силен. Что увидел, то и словил
К тому же чтение и запись — два разных процесса. Видя результат записи, почти невозможно предугадать как производилось чтение.
G>>>А понимание в инженерном деле требуется для действия.
AN>>Это смотря от поставленнй задачи.

G>Всегда. "Задача" всегда подразумевает выполнение полезного действия с полезным результатом. То есть, если нет действий, которое вам надо выполнить с программой — вам вообще нет нужды в ней разбираться. Незачем. Нефиг лезть в работающий механизм.

Повторюсь немного, поставлена задача "разобраться в программе" — какое полезное действие это подразумевает и что будет являтся результатом?
AN>>Но в любом случает требуется вначале понять/знать как эта фигня работает. И как правило, при этом требуется комплексный подход.

G>>>И если первым действием будет являться "наведение порядка" в коде, в котором вы плохо разбираетесь, святая обязанность менеджера немедленно дать таким инициативным людям по рукам.
AN>>Никто об этом не говорил, что нужно наводить порядок, так как даже в своем проекте не всегда следует это делать.

G>Рефакторинг из соображений красоты был единственным действием, для которого требуется ваше понимание. Раз вы его выполнять не собираетесь,
В некотором временном промежутке, да. Но если проблема найдена и она заслуживает внимания, то действие когда либо вполне может произойти. А что если процесс разбора не выявил никаких проблем, будет ли этот процесс совершенно бесполезным, так как действий то никаких нет. И для чего за такие бесполезные вещи иногда платят довольно большие деньги?
G>ваше "понимание", движимое абстрактной красотой,
Абстрактной она может являтся для других, для меня она конкретна.
G>не приводит вообще ни к каким действиям, и, таким образом, получается бесполезно. Что и требовалось доказать.

AN>>Тут где — то аналогия с покупкой поддержанной машины. Ведь мы же не лезем сразу в мотор. Для начала достаточно бегло взлянуть на корпус, а затем может быть детальный внешний осмотр с проверкой функционирования. И тут же составляется план действий: передние колеса заменить, найти отчего не включается правый задний поворотник (может лампочка сгорела?), салон почистить и пр.

G>Правильная аналогия — вам достались чертежи неизвестной модели автомобиля (это ваши исходники), в которые вам надо вносить изменения по рекламациям (это задача поддержки, в контексте которой ваша оценка красоты обводов кузова никому не интересна). Ваша аналогия — неправильная.
Ладно возьмем правильную. Будете ли Вы делать все изменения исключительно по чертежу даже не пытаясь взглянуть на образец?

G>В разработке ПО вы, думаю, как и я — разбираетесь получше, чем в конструировании и производстве автомобилей. Давайте без "бытовых" аналогий уровня домохозяек обойдемся.
Мне лично различные аналогии часто довольно сильно помогают. При этом, аналогия — просто другой способ изложения мысли и ничего большего. Так сказать, заход на проблему с другой стороны. Например, сколько нужно написать предложений вместо следующей аналогии, на вопрос "как вы разработали эту программу" — точно также как я ем копченную рыбу только в обратном порядке.
Вполне возможно, что не всем будет понятна данная аналогия, но кто в нее въедет, не нужно будет уже никаких слов, да и забыть будет довольно тяжело.

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

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

AN>>>В принципе мелочь, но нежелательно, "портить красоту".

SD>>Мда, с такими рассуждениями, на месте менеджера я бы задумался, чем это мои люди занимаются.

G>Менеджер для этого слишком занят. Он одну диаграмму на десяти (!) листах в цвета красит.
И что тут удивительного? Квадратики с именем класса и модуля соединенные стрелками. Листы "связаны" иерархически, каждый лист можно рассматривать отдельно вне зависимости от остальных. Кстати, в итоге получилось 17, так как в первом варианте некоторые классы были незаслужено забыты.
Ну и в догонку. Автогенерированная диаграмма ни на что не годилась, кроме как служить отправной точкой для дальнейшей обработки.
G>Для лучшего понимания системы, очевидно.
В итоге все таки понял как эта часть работает. При этом, в принципе, было бы достаточно и первого листа с верхним уровнем иерархии.
G>Правило 7+-2 сущности на лист — это для слабаков.
Не стоит слепо поклонятся правилам, даже не зная что изображено.

AN>Занимаются обнаружением проблем в проекте. Почти любая недокументированная "некрасивость" рано или поздно вылезет каким то боком. А документированная только говорит о том, что да мы знаем — это сделано плохо/неправильно, но другого решения у нас пока нет.

Вы о каком проекте? Вашем, или тредстартера? В вашем, ежели проект новый и сравнительно документированный, и у вас вагон времени на "потенциальные" улучшения, — да пожалуйста. Но я (и не только я) ведем речь о старом, плохо спроектированном продукте, который надо чинить и фиксить. В общем, поддерживать — даже не развивать.

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

AN>>Занимаются обнаружением проблем в проекте. Почти любая недокументированная "некрасивость" рано или поздно вылезет каким то боком. А документированная только говорит о том, что да мы знаем — это сделано плохо/неправильно, но другого решения у нас пока нет.

SD>Вы о каком проекте? Вашем, или тредстартера? В вашем, ежели проект новый и сравнительно документированный, и у вас вагон времени на "потенциальные" улучшения, — да пожалуйста. Но я (и не только я) ведем речь о старом, плохо спроектированном продукте, который надо чинить и фиксить. В общем, поддерживать — даже не развивать.
Это был ответ просто на общий вопрос, который вероятно ближе к моему проекту.
Но и при этом никто не агитировал заниматься улучшением проекта топикстартера, для такого огромного старика это опасно для жизни, но даже при этом знать проблемы никак не помешает.
Да и я вроде пояснил позже, что "некрасивости" выяавляются при выполнении совсем другой работы. Решение об их устранении/документировании принимается позже. Но как минимум, об этом желательно знать.

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

D>В отдел передали на поддержку и доработку большой проект (10 лет) на C++ (Visual Studio + MFC). Проект разрабатывали примерно 12-14 человек в разное время, документация есть, но скудная. И главное это ужасное качество кода.

D>Могу выделить 3 человек на этот проект. Ломаю голову как лучше поступить. Частота релизов должна быть примерно 3-4 недели (исправление критических ошибок, добавление хотел руководства \ пользователей).

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

D>Спасибо

Увы, не заметил этот топик раньше. Надеюсь, я все же не опоздал

Ключевой момент здесь — MFC. И первое, что обязательно нужно сделать — познакомиться с архитектурой MFC-приложений. Скорее всего там используется архитектура document-view. Определить это просто : если есть класс-наследник от CDocument — значит, да. Далее я предполагаю, что это так. Кроме того, я предполагаю, что авторы проекта следовали правилам этой архитектуры.

Первое, что надо сделать — найти класс-наследник от CFrameWnd. Он обычно называется CMainFrame (по крайней мере для SDI-приложений, с MDI я плохо знаком). Это основное окно, там все обработчики того, что связано с действиями на уровне главного окна. По этим обработчикам можно составить себе представление о том, на какие действия пользователя там имеется реакция и в чем она заключается. По ходу изучения этих обработчиков удастся определить, какие еще классы относятся к CMainFrame, то есть являются для него вспомогательными (внедренными в него).

Далее нужно сделать то же самое для наследника от CView. Это окно взаимодействия пользователя на уровне работы с мышью, клавиатурой и т.д.

Далее то же для наследника от CWinApp. Это класс собственно приложения.

Далее найти всех наследников от CDialog. Их будет много. Это всякие диалоги разного рода. Как правило, они не пересекаются, то есть для каждого диалога — свой(и) классы.

И наконец то же самое для класса — наследника от CDocument. Это логика приложения, то есть внутренние данные его и методы работы с ними.

Если приложение написано корректно, то эти классы не должны пересекаться. То есть к классам, относящимся к документу, не должно быть прямого (не через документ) доступа из view или mainframe, и vice versa. А из документа к view вообще обращений быть не должно.

После того, как это будет сделано, набор классов распадется (надеюсь), на несколько относительно независимых поднаборов. Эти поднаборы надо определить, то есть понять, какие классы куда относятся.

Дальше идем к обработчикам (всякие ON_XXX). Они могут быть в любом классе из вышеперечисленых. Как правило, не составляет особого труда понять, для чего этот обработчик предназначен. Трассируя его, можно понять , как он работает. Сделав это для всех обработчиков (не сразу, конечно , можно понять логику приложения.

А вообще могу дать простой совет. В примерах к Visual Studio есть несколько проектов на MFC. Если мне память не изменяет (посмотреть сейчас не могу) там есть исходники WordPad, то ли настоящего, то ли усеченного . Вот с такого примера стоит начать и разобраться в нем. Конечно, на это уйдет время, но это окупится тем, что при работе с настоящим проектом вы не будете тыкаться как слепые котята в эти классы, а сможете легко оценить, что куда относится.

Ну и последнее. Если не знаете программирование для MFC — либо не беритесь , либо освойте его. Иначе ничего не выйдет.

AN>Это был ответ просто на общий вопрос, который вероятно ближе к моему проекту.

Понятно. Вы про Фому, я про Ерему. Вам бы свою ветку открыть на тему "как я повысил эффектиность багфиксинга", это было бы полезно. А в этой ветке получилось, что мы о разном говорили.

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

AN>>Это был ответ просто на общий вопрос, который вероятно ближе к моему проекту.

SD>Понятно. Вы про Фому, я про Ерему. Вам бы свою ветку открыть на тему "как я повысил эффектиность багфиксинга", это было бы полезно. А в этой ветке получилось, что мы о разном говорили.
Обычно в середине разговора не бегут в другую комнату.
Просто завязалась дискуссия об полезности/бесполезности диаграмм, которая была в принципе, в ключе данной темы. А все что "про меня" это просто были примеры полезности диаграмм, с моей точки зрения и больше ничего не подразумевалось

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

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

Это, наверное, был очень большой шеф, которому понадобилось сделать презентацию инвесторам. А инвесторы — не иначе, как программисты со стажем, у которых мозги ещё не проветрились после вакханалии ООП. Иначе я с очень большим трудом понимаю, на кой такие художества — заняться больше нечем?

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

Такими примерами ты дискредитируешь саму идею построения диаграмм. Ну, не используемый класс, ну, в другом месте, да он там ещё сто лет никому нужен бы не был, ан нет, вот понадобилось шефу малярное искусство... Зазеркалье какое-то, право слово.

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

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

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

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

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

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

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