В отдел передали на поддержку и доработку большой проект (10 лет) на C++ (Visual Studio + MFC). Проект разрабатывали примерно 12-14 человек в разное время, документация есть, но скудная. И главное это ужасное качество кода.
Могу выделить 3 человек на этот проект. Ломаю голову как лучше поступить. Частота релизов должна быть примерно 3-4 недели (исправление критических ошибок, добавление хотел руководства \ пользователей).
Посоветуйте, как бы вы организовали разработку.
Как я себе это вижу:
1. UML по исходникам
2. Понимание архитектуры и её поверхностное документирование
3. Закрепить за 3 людьми определенные области в этой архитектуре
4. Люди пишут Unit Test'ы, выполняют текущие задачи по исправлению ошибок, проводят в свободное время рефакторинг
Кажется, надо позвать Тома Круза для помощи. Но все же...
D>2. Понимание архитектуры и её поверхностное документирование
А что будете делать в случае отсутствия архитектуры? Или же ужасное качество кода не касается центральных и контрольных элементов системе?
D>4. Люди пишут Unit Test'ы, выполняют текущие задачи по исправлению ошибок, проводят в свободное время рефакторинг
Свободное оплачиваемое время на саппорте? Хм, оно существует?
И все же, если архитектура такая уж горькая, то может бы продумать улучшение ее и измерить сроки такого процесса?
Как показывает опыт, ни понимание архитектуры разработчиками, ни вообще ее наличие, не являются необходимыми условиями для успешной разработки программ любой сложности и размера.
Серьезно. Такова грубая реальность.
Так что просто берите своих программистов — и бросайте в бой, давайте сразу какие-нибудь баги. Естественно, первое время скорость фиксов будет низкой, и это надо учитывать.
Про UML и прочее сразу могу сказать, что это просто трата времени. Проблемы будут все одни и те же — время на UML будет потрачено, и, возможно, много, понимание кода разработчиками от этого не улучшится, разработчикам впадлу будет читать доки, на которые кто-то убил столько времени, а потом эти доки рассинхронизируются с кодом, и на них все забьют, ну и так далее. Проходили все это сто раз.
Извините за мой французский, как сказал опытнейший и умнейший участник этого форума под псевдонимом Gaperton, "Читай код, сука!" Как ни печально и грубо это звучит, но это правда жизни в реалиях сегодняшних недоразвитых технологий разработки ПО.
Вот такое мое мнение. Опыт программирования у меня ~7 лет, в т.ч. участвовал в разработке большого проекта с несколькими миллионами пользователей (и продолжаю).
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Didro, Вы писали:
А>Как показывает опыт, ни понимание архитектуры разработчиками, ни вообще ее наличие, не являются необходимыми условиями для успешной разработки программ любой сложности и размера.
Странно, у меня опыт отчего-то другое показывет
А>Про UML и прочее сразу могу сказать, что это просто трата времени.
кому как, думаю. По крайней мере, достаточно иметь диаграмму классов. Да, на ее приведение в божеский вид потребуется относительно много времени и да, потом она вероятно и не понадобится.
Но задача, я бы сказал самоубийственная. За 10 лет там такого наворотили, костыли на костыле. Исправляя одно, убивается другое.
Здравствуйте, AlexNek, Вы писали:
AN>Странно, у меня опыт отчего-то другое показывет AN>... AN>кому как, думаю.
Ну если ты самый умный, чего спрашиваешь тогда? Меня поражают люди, которые сначала спрашивают совета, а потом начинают показывать свое интеллектуальное превосходство ответившему.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, AlexNek, Вы писали:
AN>>Странно, у меня опыт отчего-то другое показывет AN>>... AN>>кому как, думаю.
А>Ну если ты самый умный, чего спрашиваешь тогда? Меня поражают люди, которые сначала спрашивают совета, а потом начинают показывать свое интеллектуальное превосходство ответившему.
Эээ...товарисч, вы чего с бодуна?! Это не ТС вам ответил. А по факту, меня удивляют люди которые говорят, что наличие архитектуры в проекте, который будет жить дольше семестра в институте, не требует наличия архитектуры. Продукт не важен — главное бабло срубить, а после — нас хоть потоп.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, AlexNek, Вы писали:
AN>>Странно, у меня опыт отчего-то другое показывет AN>>... AN>>кому как, думаю.
А>Ну если ты самый умный, чего спрашиваешь тогда? Меня поражают люди, которые сначала спрашивают совета, а потом начинают показывать свое интеллектуальное превосходство ответившему.
Мне кажется Вы меня с кем то перепутали
— Во первых, это не моя тема
— Во вторых, я просто высказал свое мнение ни на что не претендуя.
— В третьих, где вы нашли противопоставление или показушность?
D>Как я себе это вижу: D>1. UML по исходникам D>2. Понимание архитектуры и её поверхностное документирование D>3. Закрепить за 3 людьми определенные области в этой архитектуре D>4. Люди пишут Unit Test'ы, выполняют текущие задачи по исправлению ошибок, проводят в свободное время рефакторинг
Как это будет в реальности:
1. Вот из-за того бага все наши клиенты застопорились, фиксите срочно!
2. Сами говорили, архитектура плохая, вот и не трогайте ничего, никакого "полного рефакторинга" и прочих разрушительных для проектов вида "карточный домик" вещей.
3. Никого никто крепить не будет, если архитектуры нет, значит, ее нет.
4. А вот с тестами — это категорически правильно!!! Только не юнит, а вообще — тесты, тесты, тесты, тесты! Как тов. С. Балмер в знаменитом клипе "Developers, developers".
Исходя из опыта и реальности — забудьте про красивые слова "архитектура", UML, "документировать". У вас же не забрали право консультироваться с изначальными разработчиками? Вот и пробуйте при заходе в тупик совершать "звонок другу" с конкретными вопросами "а почему вот там сделано вот так".
И — тесты, тесты, тесты. Чем быстрее вы автоматизируете тестирование, тем проще вам будет вносить изменения, не нарушающие стабильную работу системы (это самое сложное для проектов с 10-летним легаси).
Здравствуйте, AlexNek, Вы писали:
А>>Как показывает опыт, ни понимание архитектуры разработчиками, ни вообще ее наличие, не являются необходимыми условиями для успешной разработки программ любой сложности и размера. AN>Странно, у меня опыт отчего-то другое показывет
Какой опыт, и что именно вам подсказывает? Вы расскажите, людям-то интересно.
А>>Про UML и прочее сразу могу сказать, что это просто трата времени. AN>кому как, думаю. По крайней мере, достаточно иметь диаграмму классов. Да, на ее приведение в божеский вид потребуется относительно много времени и да, потом она вероятно и не понадобится.
Берется Rational Rose, всасывается код в режиме reverse engineering, после чего любая диаграмма классов строится за пару минут.
Это совершенно необходимо проделать, чтобы убедится в полной бесполезности имения диаграмм классов в данной ситуации. Рекомендую. По другому обычно до людей это не доходит.
AN>Но задача, я бы сказал самоубийственная. За 10 лет там такого наворотили, костыли на костыле. Исправляя одно, убивается другое.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AlexNek, Вы писали:
А>>>Как показывает опыт, ни понимание архитектуры разработчиками, ни вообще ее наличие, не являются необходимыми условиями для успешной разработки программ любой сложности и размера. AN>>Странно, у меня опыт отчего-то другое показывет
G>Какой опыт, и что именно вам подсказывает? Вы расскажите, людям-то интересно.
Что именно правильный концепт (арихитектура) проекта определяет его успешность и если правка делается лишь бы как, без понимания "как работает", то в итоге получается полная каша. И для "убийства" данной каши достаточно легкого ветерка.
А>>>Про UML и прочее сразу могу сказать, что это просто трата времени. AN>>кому как, думаю. По крайней мере, достаточно иметь диаграмму классов. Да, на ее приведение в божеский вид потребуется относительно много времени и да, потом она вероятно и не понадобится.
G>Берется Rational Rose, всасывается код в режиме reverse engineering, после чего любая диаграмма классов строится за пару минут.
Я так предполагаю, что классов за это время набралось порядочно, уж не меннее пары сотен там точно есть и что нам даст необработанная диаграмма с более чем 100 классами? Видимо поэтому и делается утверждение о ее бесполезности.
Уж не помню сколько было классов на плакате об MFC, но о полнейшей бесполезности ентого я бы не говорил.
Однако исключения бывают и в другую сторону, например, когда сишник просто обвертывает свой код в классы.
Однако, в любом случае диаграмму классов весьма полезно увидеть хотя бы раз, по крайней мере для меня лично.
G>Это совершенно необходимо проделать, чтобы убедится в полной бесполезности имения диаграмм классов в данной ситуации. Рекомендую. По другому обычно до людей это не доходит.
AN>>Но задача, я бы сказал самоубийственная. За 10 лет там такого наворотили, костыли на костыле. Исправляя одно, убивается другое.
G>Почему же? Опыт был самоубийственный?
Ну пока до этого не дошло, но с течением времени долгоживущие проекты довольно часто превращаются в груду застывшей вермишели, так как правят его все кому не лень и как можно быстрее. По счастью, бывают и исключения, но судя по высказыанию о качестве кода это не тот случай.
AN>Что именно правильный концепт (арихитектура) проекта определяет его успешность и если правка делается лишь бы как, без понимания "как работает", то в итоге получается полная каша. И для "убийства" данной каши достаточно легкого ветерка.
Гм.
У вас есть проект, которому уже 10 лет. Он явно успешный (или был успешным), иначе бы его не сдавали на саппорт, а закрывали бы. Да и в целом, неуспешные проекты по 10 лет не пилят. Но, как вы сами отмечаете, у него нет "правильного концепта (архитектуры)". Значит, все-таки, успешность проекта определяется отнюдь не архитектурой
А то, что для "убийства" достаточно легкого ветерка — дык такое на любом проекте, который не тестируется как следует.
AN>Однако, в любом случае диаграмму классов весьма полезно увидеть хотя бы раз, по крайней мере для меня лично.
Вот тов. Gaperton и предлагает ее вам один раз увидеть. Втащите, повоюйте с падучестью Rose (10 лет по 12 человек = это 120 человеко-лет, это весьма большой проект, я вообще сомневаюсь, что rose осилит), попробуйте Sparxx Enterprise Architect (мне софтина больше по душе, ибо аккуратнее сделана), тоже пободайтесь. В итоге сгенерируйте "безумного ежа" (мое наименование диаграммы классов для проекта с большим легаси), и тогда уже убедитесь, что Gaperton сказал вам правду
AN>Ну пока до этого не дошло, но с течением времени долгоживущие проекты довольно часто превращаются в груду застывшей вермишели, так как правят его все кому не лень и как можно быстрее. По счастью, бывают и исключения, но судя по высказыанию о качестве кода это не тот случай.
SD>Вот тов. Gaperton и предлагает ее вам один раз увидеть. Втащите, повоюйте с падучестью Rose (10 лет по 12 человек = это 120 человеко-лет, это весьма большой проект, я вообще сомневаюсь, что rose осилит), попробуйте Sparxx Enterprise Architect (мне софтина больше по душе, ибо аккуратнее сделана), тоже пободайтесь. В итоге сгенерируйте "безумного ежа" (мое наименование диаграммы классов для проекта с большим легаси), и тогда уже убедитесь, что Gaperton сказал вам правду
Странно, что UML в последнее время стал ассоциироваться в основном только с автоматически генерируемыми диаграмами классов. В UML вообще-то и другие диаграмы есть, которые может и не генерятся по мановению волшебной кнопки, а требуют поразмыслить над классами, подсистемами, но очевидно, что полезность их намного выше. Если один чел посидит денек и налабает наример component, sequence, state machine, activity diagram-ы, и потом покажет другим — то понимание того как оно все там устроено может заметно увеличится у всех. Да и те автоматически генерируемые если немного подправить — например разбить на 10 небольших вместо одной, то и они пригодятся. Трудно назвать правильным полное отрицание UML, но конечно надо знать меру
Здравствуйте, SkyDance, Вы писали:
AN>>Что именно правильный концепт (арихитектура) проекта определяет его успешность и если правка делается лишь бы как, без понимания "как работает", то в итоге получается полная каша. И для "убийства" данной каши достаточно легкого ветерка.
SD>Гм. SD>У вас есть проект, которому уже 10 лет. Он явно успешный (или был успешным), иначе бы его не сдавали на саппорт, а закрывали бы. Да и в целом, неуспешные проекты по 10 лет не пилят. Но, как вы сами отмечаете, у него нет "правильного концепта (архитектуры)". Значит, все-таки, успешность проекта определяется отнюдь не архитектурой
Это только означает что у нас разный взгляд на "успешность" проекта.
Как я понял, с вашей сторону успешность означает возможность заработать на проекте деньгу.
Для меня успешность — это когда, как минимум ПМ, и разработчики не имеют страшной "головной боли" по проекту. SD>А то, что для "убийства" достаточно легкого ветерка — дык такое на любом проекте, который не тестируется как следует.
То есть если мы "спагетти проект" обложим со всех сторон тестами он станет "более устойчив" к правке?
Но это видимо опять просто другая точка зрения
AN>>Однако, в любом случае диаграмму классов весьма полезно увидеть хотя бы раз, по крайней мере для меня лично.
SD>Вот тов. Gaperton и предлагает ее вам один раз увидеть. Втащите, повоюйте с падучестью Rose (10 лет по 12 человек = это 120 человеко-лет, это весьма большой проект, я вообще сомневаюсь, что rose осилит), попробуйте Sparxx Enterprise Architect (мне софтина больше по душе, ибо аккуратнее сделана), тоже пободайтесь. В итоге сгенерируйте "безумного ежа" (мое наименование диаграммы классов для проекта с большим легаси), и тогда уже убедитесь, что Gaperton сказал вам правду
О Розе мы забыли весьма давно после первых же тестов. И "любимого" софта у меня нет до сих пор. Каждый имеет свои заморочки, особенно на больших проектах.
Но допустим, что "безумного ежа" мы все же получили. (Наверняка весь проект — это не один "соурсе проект".) Так вот теперь и наступает самое интересное и долгое. Я называю это разбивкой на кластеры. В студии для этого есть иконка с кружочками. "Связанные" классы убираются в блок и тогда вместо нескольких десятков классов остается один блок. После какого то количества итераций остается уже обозримое количество блоков, при этом довольно часто находятся ошибки/недосмотры иерархии классов. В каждый период времени я делал эту разбивку по разному, но всегда в процессе данной работы проступает "картинка" проекта, хотя бы в голове.
AN>>Ну пока до этого не дошло, но с течением времени долгоживущие проекты довольно часто превращаются в груду застывшей вермишели, так как правят его все кому не лень и как можно быстрее. По счастью, бывают и исключения, но судя по высказыанию о качестве кода это не тот случай.
SD>Так если проект неуспешный, его закроют
Проект может приносить деньгу, но при этом софт может не быть успешным. Хотя это опять уже другая тема и каждый может определять успех по своему.
Здравствуйте, qqqqq, Вы писали:
Q>Если один чел посидит денек и налабает наример component, sequence, state machine, activity diagram-ы, и потом покажет другим — то понимание того как оно все там устроено может заметно увеличится у всех.
Ну если за один день можно разобраться с проектом, тогда зачем вообще эти диаграммы? Дать всем программистам день — пускай все и разберутся с кодом.
Проблема "диаграмм" и архитектуры в том, что если проект действительно сложный, диаграммы не помогают, а если не сложный — то они не требуются. Та же ерунда как с рисованием алгоритмов в виде блок-схем.
Ну и второй момент — не надо недооценивать программистов. Если их пнуть, они практически в любом коде могут разобраться за довольно короткий период. Проверено не раз.
Вы посмотрите на OpenSource — там множество проектов состоит из отборнейшего говнокода безо всякой документации и даже без комментариев в коде, и ничего, все прекрасно разбираются в этом, комьюнити работает.
Мне самому эта мысль кажется дикой, но, похоже, важность архитектуры вообще принято переоценивать. Я и сам по началу был сосредоточен на построении идеальных архитектур, но позже убедился, что экономическая целесообразность все быстро расставляет по своим местам.
Вообще, я работаю над похожим проектом: он тоже большой, старый, но активно развивается при этом, и постоянно все разработчики ноют, что надо рефакторить, переделывать архитектуру, а он все идет и развивается, и деньги приносит. Так оглядываешься назад и становится очевидно, что и не очень-то и нужна она была эта "правильная архитектура".
AN>Это только означает что у нас разный взгляд на "успешность" проекта.
Похоже на то.
AN>Как я понял, с вашей сторону успешность означает возможность заработать на проекте деньгу. AN>Для меня успешность — это когда, как минимум ПМ, и разработчики не имеют страшной "головной боли" по проекту.
Простите, но это не "головная боль", а источник дохода ПМ и разработчиков. У вас какое-то извращенное понятие об успехе. Если бы проект был неуспешен, всех бы разогнали и уволили. Это для вас лучше?
AN>То есть если мы "спагетти проект" обложим со всех сторон тестами он станет "более устойчив" к правке?
Более того, сами правки станут значительно более быстрыми. Поверьте, всякие там TDD не на пустом месте возникли.
AN>Но допустим, что "безумного ежа" мы все же получили. (Наверняка весь проект — это не один "соурсе проект".) Так вот теперь и наступает самое интересное и долгое. Я называю это разбивкой на кластеры. В студии для этого есть иконка с кружочками. "Связанные" классы убираются в блок и тогда вместо нескольких десятков классов остается один блок. После какого то количества итераций остается уже обозримое количество блоков, при этом довольно часто находятся ошибки/недосмотры иерархии классов. В каждый период времени я делал эту разбивку по разному, но всегда в процессе данной работы проступает "картинка" проекта, хотя бы в голове.
Здорово! В принципе, вы могли бы эту "картинку" получить от первоначальных разработчиков. Просто попросили бы объяснить. Вам бы нарисовали, на доске ли, или на бумажке. Но это уже ваш выбор, самостоятельное освоение имеет свои плюсы — больше граблей видно свежим взглядом. С другой стороны, всегда полезно понимать логику и задумку первоначальных разработчиков.
AN>Проект может приносить деньгу, но при этом софт может не быть успешным. Хотя это опять уже другая тема и каждый может определять успех по своему.
Если вы работаете не из благотворительности, то для вас проект — источник дохода. Он может быть менее успешен, чем какие-то другие проекты, но при всем этом он успешнее 70% проектов вообще (ЕМНИП, именно такие цифры обычно называют при оценке количества провалившихся проектов).
Как я понял, задача стоит в освоении строго сложного проекта, с кодом которого многие или может даже все не знакомы. Ну надо же что-то делать. Если люди разбираются в UML то можно просто нарисовать диаграммы, чтобы хоть было понятно что к чему. Или что? Сказать: "Уууу, да это все очень все сложно" и забить на все это, типа ну и ладно, как-нибудь разберемся со временем. И дело даже не в изменении архитектуры, иногда люди годами работаютнад большим проектом, поддерживают, фиксят баги, и т.п. но при этом никто понимает как или почему же это все работает, потому что того, кто все это заварил уже повысилили до недосягаемого уровня или например он свалил уже, а у остальных нет возможности охватить все целиком потому как нет документации. А ее почти никогда нет или она есть но устарела и не соответсвтвует коду. Ну или например другая крайность — огромная куча документации на 100+ классов (из doxygen) но поди прочитай это все. Пока дойдешь до 100 класса уже забудешь что первые 5 делали. Очень часто визуальная информацию в картинках в том числе и UML диаграммах намного проще понять и поддерживать легче.
Здравствуйте, Gaperton, Вы писали:
G>Берется Rational Rose, всасывается код в режиме reverse engineering, после чего любая диаграмма классов строится за пару минут.
G>Это совершенно необходимо проделать, чтобы убедится в полной бесполезности имения диаграмм классов в данной ситуации. Рекомендую. По другому обычно до людей это не доходит.
Это всего лишь говорит о бесполезности автоматической генерации диаграмм.
Здравствуйте, Аноним, Вы писали:
А>Мне самому эта мысль кажется дикой, но, похоже, важность архитектуры вообще принято переоценивать. Я и сам по началу был сосредоточен на построении идеальных архитектур, но позже убедился, что экономическая целесообразность все быстро расставляет по своим местам.
У меня сейчас есть уникальная возможность сравнить два разных проекта,
которые разрабатывают практически одно и то же.
В первом проекте тратят время на архитектуру, концепции и прочие дела.
Не всегда все идеально и бардак в коде присутствует, но этот бардак обычно локален.
Т.е. если есть компонента, то с четким, документированным интерфейсом,
который родился в результате интенсивных дискуссий.
А вот реализация интерфейсов бывает далеко не всегда идеальной.
На втором проекте чистое ковбойское программирование.
Ни четких интерфейсов, ни документации, ни людей, которые реально понимают как работает система.
Типичная самооргизовавшая система, которая каким-то магическим образом умудряется что-то делать.
Несмотря на хаос проект развивается и тоже приносит деньги.
Но есть одно но...
На первом проекте в 3 раза меньше людей и они быстрее реагируют на запросы рынка.
Что лучше — это неоднозначный вопрос.
Про первый проект можно сказать, что они явно эффективнее
(это объективно меряется потому что делают они практически одно и то же).
Ну а про второй проект можно сказать, что он дает работу большиму числу людей
Re: Поддержка большого и старого С++ проекта
От:
Аноним
Дата:
30.08.11 09:11
Оценка:
Здравствуйте, Didro, Вы писали:
D>В отдел передали на поддержку и доработку большой проект (10 лет) на C++ (Visual Studio + MFC). Проект разрабатывали примерно 12-14 человек в разное время, документация есть, но скудная. И главное это ужасное качество кода.
D>Могу выделить 3 человек на этот проект. Ломаю голову как лучше поступить. Частота релизов должна быть примерно 3-4 недели (исправление критических ошибок, добавление хотел руководства \ пользователей).
D>4. Люди пишут Unit Test'ы, выполняют текущие задачи по исправлению ошибок, проводят в свободное время рефакторинг
2011 год. Планета Земля. Трем программистам поручают внедрить Unit-тестирование в 130-человеколетний проект на MFC с "ужасным" качеством кода. Чтобы выполнить задание у них есть три недели...
Жестоко. У вас там, наверно, суровые программисты работают. Они настолько суровы, что UML диаграммы рисуют взглядом, а баги фиксятся сами до того, как они сядут за компьютер.
Здравствуйте, Didro, Вы писали:
D>В отдел передали на поддержку и доработку большой проект (10 лет) на C++ (Visual Studio + MFC). Проект разрабатывали примерно 12-14 человек в разное время, документация есть, но скудная. И главное это ужасное качество кода.
Есть разные программисты. Одним (1) нужна архитектура, общая идея, документация, строгое использование определенных правил. Любой код, который как-то нарушает эти правила, называется говнокодом (ужасным кодом). Другие (2) больше привыкли разбираться с кодом, схватывать что он должен делать, общую идею.
Конечно, в реале у каждого человека развиты в какой-то мере оба этих скила, а у кого-то может быть, что они оба прокачаны хорошо. Главное, что на такой проект не следует набирать людей, у которых не прокачан скил (2). Если у самого скил (2) не прокачан, то лучше мягко отказаться от участия в таком проекте.
Ну а далее разбираться в коде, смотреть что там как сделано, исправлять. Если можно и есть время написать тесты, хорошо
Здравствуйте, SkyDance, Вы писали:
AN>>Однако, в любом случае диаграмму классов весьма полезно увидеть хотя бы раз, по крайней мере для меня лично.
SD>Вот тов. Gaperton и предлагает ее вам один раз увидеть. Втащите, повоюйте с падучестью Rose (10 лет по 12 человек = это 120 человеко-лет, это весьма большой проект, я вообще сомневаюсь, что rose осилит).
Осилит. Я ее еще лет 10 назад на 50-меговых исходниках CQG пускал. Легко справляется.
Здравствуйте, bkat, Вы писали:
G>>Берется Rational Rose, всасывается код в режиме reverse engineering, после чего любая диаграмма классов строится за пару минут.
G>>Это совершенно необходимо проделать, чтобы убедится в полной бесполезности имения диаграмм классов в данной ситуации. Рекомендую. По другому обычно до людей это не доходит.
B>Это всего лишь говорит о бесполезности автоматической генерации диаграмм.
Давай всего лишь будем читать что написано. Я написал — после чего любая диаграмма классов строится за пару минут. Я разве где-то писал про то, что надо смотреть автоматически сгенерированные диаграмм?
Автогенеренные пауки удаляются сразу. "Любая диаграмма" в Розе строится драг-энж-дропом — бросаешь на чистый лист интересные тебе классы, они сами в диаграмму связываются. После чего — скрываешь на диаграмме с классов те мемберы, которые тебе не интересны — и вуаля. Несколько минут на любую диаграмму классов.
Что, разумеется, ничерта тебе не поможет. Люди в ветке все правильно говорят — если система большая, то диаграмма не поможет, если маленькая — то она не нужна.
А я добавлю — ценность не в диаграмме, а в тех процессах, которые происходят у тебя в мозгу, когда ты ее составляешь, ползая по коду. После составления диаграмму можно немедленно порвать — она нафиг не нужна.
И диаграмма классов — наименее ценна их всех моделей. Поток данных куда важнее. Для протоколов — конечные автоматы важнее. Это понимание извлекается только из кода, и глупо пытаться жульничать, избегая с ним контакта. Все равно тебе рано или поздно придется столкнуться с кодом, и ты будешь смотреть на него как баран на новые ворота.
Желание "видеть диаграмму", и стенания по поводу отсутствующей документации — симптом кодобоязни.
Здравствуйте, SkyDance, Вы писали:
AN>>Это только означает что у нас разный взгляд на "успешность" проекта.
SD>Похоже на то.
AN>>Как я понял, с вашей сторону успешность означает возможность заработать на проекте деньгу. AN>>Для меня успешность — это когда, как минимум ПМ, и разработчики не имеют страшной "головной боли" по проекту.
SD>Простите, но это не "головная боль", а источник дохода ПМ и разработчиков. У вас какое-то извращенное понятие об успехе. Если бы проект был неуспешен, всех бы разогнали и уволили. Это для вас лучше?
Похоже проблема шире, чем казалось. По крайней мере, я бы еще ввел понятие продукта за который конечные пользователи платят денюжку. И речь тогда будет идти прежде всего об успешном продукте. Софтверный проект при этом может быть как и данным продуктом, так и какой то частью. И если идти от продукта к проекту, то "устройство" проекта никого не интересует, важны видимо удобство и надежность софта. Видимо это и имелось Вами в виду. Если же пойти от проекта к продукту и попробовать вычислить корреляцию между хорошо разработанным проектом и успешным продуктом, то мне думается она будет довольно высока.
С другой стороны, заказчик проекта не ставит задание разработать успешный продукт, он заказывает конкретный продукт и хочет получить "успешный проект" — разработанный в срок, при запланированных ресурсах, с приемлемым количеством ошибок, удобный в сопровождении/развитии и пр. Мне думается, что непродуманный "спагетти проект" никак не пойдет на звание такого "успешного проекта", что однако не запрещает ему выступать в роли успешного продукта.
AN>>То есть если мы "спагетти проект" обложим со всех сторон тестами он станет "более устойчив" к правке?
SD>Более того, сами правки станут значительно более быстрыми. Поверьте, всякие там TDD не на пустом месте возникли.
Весьма тяжело это представить. Это что то типа алгоритма как из Г. сделать конфетку? AN>>Но допустим, что "безумного ежа" мы все же получили. (Наверняка весь проект — это не один "соурсе проект".) Так вот теперь и наступает самое интересное и долгое. Я называю это разбивкой на кластеры. В студии для этого есть иконка с кружочками. "Связанные" классы убираются в блок и тогда вместо нескольких десятков классов остается один блок. После какого то количества итераций остается уже обозримое количество блоков, при этом довольно часто находятся ошибки/недосмотры иерархии классов. В каждый период времени я делал эту разбивку по разному, но всегда в процессе данной работы проступает "картинка" проекта, хотя бы в голове.
SD>Здорово! В принципе, вы могли бы эту "картинку" получить от первоначальных разработчиков. Просто попросили бы объяснить. Вам бы нарисовали, на доске ли, или на бумажке.
Для это нужно как минимум иметь подобную возможность. SD>Но это уже ваш выбор, самостоятельное освоение имеет свои плюсы — больше граблей видно свежим взглядом. С другой стороны, всегда полезно понимать логику и задумку первоначальных разработчиков.
AN>>Проект может приносить деньгу, но при этом софт может не быть успешным. Хотя это опять уже другая тема и каждый может определять успех по своему.
SD>Если вы работаете не из благотворительности, то для вас проект — источник дохода.
точнее не проект, а работа. SD>Он может быть менее успешен, чем какие-то другие проекты, но при всем этом он успешнее 70% проектов вообще (ЕМНИП, именно такие цифры обычно называют при оценке количества провалившихся проектов).
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, bkat, Вы писали:
G>>>Берется Rational Rose, всасывается код в режиме reverse engineering, после чего любая диаграмма классов строится за пару минут.
G>>>Это совершенно необходимо проделать, чтобы убедится в полной бесполезности имения диаграмм классов в данной ситуации. Рекомендую. По другому обычно до людей это не доходит.
B>>Это всего лишь говорит о бесполезности автоматической генерации диаграмм.
G>Давай всего лишь будем читать что написано. Я написал — после чего любая диаграмма классов строится за пару минут. Я разве где-то писал про то, что надо смотреть автоматически сгенерированные диаграмм?
G>Автогенеренные пауки удаляются сразу. "Любая диаграмма" в Розе строится драг-энж-дропом — бросаешь на чистый лист интересные тебе классы, они сами в диаграмму связываются. После чего — скрываешь на диаграмме с классов те мемберы, которые тебе не интересны — и вуаля. Несколько минут на любую диаграмму классов.
Несколько минут при условии, что ты знаешь, что ты хочешь показать.
G>Что, разумеется, ничерта тебе не поможет. Люди в ветке все правильно говорят — если система большая, то диаграмма не поможет, если маленькая — то она не нужна.
Хорошие диаграммы помогают. Но спорить абсттрактно бесполезно.
Надо брать конкретные примеры и обсуждать, на что естесвенно нету времени.
G>А я добавлю — ценность не в диаграмме, а в тех процессах, которые происходят у тебя в мозгу, когда ты ее составляешь, ползая по коду. После составления диаграмму можно немедленно порвать — она нафиг не нужна.
G>И диаграмма классов — наименее ценна их всех моделей. Поток данных куда важнее. Для протоколов — конечные автоматы важнее. Это понимание извлекается только из кода, и глупо пытаться жульничать, избегая с ним контакта. Все равно тебе рано или поздно придется столкнуться с кодом, и ты будешь смотреть на него как баран на новые ворота.
Ну слава богу. Хорошо, что хоть признал что есть и другие диаграммы.
G>Желание "видеть диаграмму", и стенания по поводу отсутствующей документации — симптом кодобоязни.
Одно другому не мешает.
Либо у тебя есть понимание как работает система и ты можешь передать это понимае другому.
Либо этого понимания нету.
Если понимание есть, то ты сможешь это выразить и с помощью диаграмм в тех случаях когда в них есть смысл.
Огульное отрицание диаграмм — это экстремизм в чистом виде.
Впрочем на этом форуме это совсем не проблема
Здравствуйте, Gaperton, Вы писали:
G>Давай всего лишь будем читать что написано. Я написал — после чего любая диаграмма классов строится за пару минут. Я разве где-то писал про то, что надо смотреть автоматически сгенерированные диаграмм?
А не нужна любая. Нужна полезная. К сожалению, ее за пару минут не построишь.
G>Автогенеренные пауки удаляются сразу. "Любая диаграмма" в Розе строится драг-энж-дропом — бросаешь на чистый лист интересные тебе классы, они сами в диаграмму связываются. После чего — скрываешь на диаграмме с классов те мемберы, которые тебе не интересны — и вуаля. Несколько минут на любую диаграмму классов.
G>Что, разумеется, ничерта тебе не поможет. Люди в ветке все правильно говорят — если система большая, то диаграмма не поможет, если маленькая — то она не нужна.
G>А я добавлю — ценность не в диаграмме, а в тех процессах, которые происходят у тебя в мозгу, когда ты ее составляешь, ползая по коду. После составления диаграмму можно немедленно порвать — она нафиг не нужна.
Ползая по коду ты делаешь определенные (полезные для понимания кода) выводы. Вот они то и должны быть отображены на диаграмме. Тогда она будет полезной. И ее не придется немедленно рвать — она можеть быть полезной, даже если в дальнейшем станет частично не верной.
G>Желание "видеть диаграмму", и стенания по поводу отсутствующей документации — симптом кодобоязни.
Здравствуйте, TimurSPB, Вы писали:
D>>1. UML по исходникам TSP>О да. Я пробовал такой подход. TSP> TSP>Это конечно вносит ясность
Как минимум, на этом уровне нужно оставить только наследование и иметь возможность перейти от "дерева" к "сети", но даже и эту диаграмму можно попробовать разгрести руками. При этом конечный результат не столь уж и важен. Важем сам процесс разгребания, именно он дает информацию о структуре проекта.
AN>Как минимум, на этом уровне нужно оставить только наследование и иметь возможность перейти от "дерева" к "сети", но даже и эту диаграмму можно попробовать разгрести руками. При этом конечный результат не столь уж и важен. Важем сам процесс разгребания, именно он дает информацию о структуре проекта.
Так копаться можно бесконечно. В моем случае были разработчики, которые в курсе основных сущностей в проекте. Были выделены несколько ключевых классов, которые были включены в автоматическую генерацию. Потом руками диаграмма приводилась в приличный вид и обрастала коментариями. Основное содержание работы — вытягивание информации о проекте от всех кто причастен. А UML и автогенерация только инструмент.
Здравствуйте, TimurSPB, Вы писали:
AN>>Как минимум, на этом уровне нужно оставить только наследование и иметь возможность перейти от "дерева" к "сети", но даже и эту диаграмму можно попробовать разгрести руками. При этом конечный результат не столь уж и важен. Важем сам процесс разгребания, именно он дает информацию о структуре проекта.
TSP>Так копаться можно бесконечно.
Бесконечно обычно не требуется. Вопрос только для чего нам нужна диаграмма. Только для себя или для других также? TSP>В моем случае были разработчики, которые в курсе основных сущностей в проекте. Были выделены несколько ключевых классов, которые были включены в автоматическую генерацию. Потом руками диаграмма приводилась в приличный вид и обрастала коментариями. TSP>Основное содержание работы — вытягивание информации о проекте от всех кто причастен.
Это, если есть такая возможность. TSP>А UML и автогенерация только инструмент.
Нужно только знать какими инструментами и как пользоваться.
Можно ведь и исключительно нотепадом пользоваться, просто каждый решает это для себя сам в каждом конкретном случае.
Здравствуйте, Буравчик, Вы писали:
G>>Давай всего лишь будем читать что написано. Я написал — после чего любая диаграмма классов строится за пару минут. Я разве где-то писал про то, что надо смотреть автоматически сгенерированные диаграмм?
Б>А не нужна любая. Нужна полезная. К сожалению, ее за пару минут не построишь.
Построишь. Диаграмма классов строится из кода однозначным образом, единственное, что ты указываешь — это какие классы на листе должны присутствовать.
G>>А я добавлю — ценность не в диаграмме, а в тех процессах, которые происходят у тебя в мозгу, когда ты ее составляешь, ползая по коду. После составления диаграмму можно немедленно порвать — она нафиг не нужна.
Б>Ползая по коду ты делаешь определенные (полезные для понимания кода) выводы. Вот они то и должны быть отображены на диаграмме. Тогда она будет полезной. И ее не придется немедленно рвать — она можеть быть полезной, даже если в дальнейшем станет частично не верной.
Никаких полезных выводов (и вообще — выводов) на диаграмме классов отразить нельзя. Она строится из кода однозначным образом.
G>>Желание "видеть диаграмму", и стенания по поводу отсутствующей документации — симптом кодобоязни.
Б>Не верно.
Здравствуйте, TimurSPB, Вы писали:
TSP>Это конечно вносит ясность
Это конечно не вносит ясности.
Начинать процесс понимания системы надо не с диаграмм классов.
С кода, кстати, тоже начинать нет смысла.
Начинать стоит с требований, если они есть.
Если нету, то надо просто тупо играться с системой, чтобы понять какие она решает задачи.
Не поняв, что делает система, практически нереально понять как она это делает.
Потом можно опускаться дальше в дебри, к примеру выделив модули/подсистемы и подобное.
Модули/подсистемы уже можно показать на простой обозримой картинке.
Если такая картинка есть, то она здорово экономит время для других.
До диаграмм классов/объектов дело тоже вполне может дойти, если в них есть смысл.
Ну и не стоит забывать, что кроме диаграмм классов есть и другие.
Документировать каждый бит конечно же нет особого смысла.
Здравствуйте, bkat, Вы писали:
G>>Автогенеренные пауки удаляются сразу. "Любая диаграмма" в Розе строится драг-энж-дропом — бросаешь на чистый лист интересные тебе классы, они сами в диаграмму связываются. После чего — скрываешь на диаграмме с классов те мемберы, которые тебе не интересны — и вуаля. Несколько минут на любую диаграмму классов.
B>Несколько минут при условии, что ты знаешь, что ты хочешь показать.
Все что тебе надо знать — это список классов, который ты хочешь показать. И даже если я тебе перечислю их названия — ты в реальной ситуации ничерта из диаграммы не поймешь. Набросать тебе фрагмент для примера? Вот что такое, по твоему, BarServer и ContractServer? Классы так называются. И что?
И доверять диаграмме, которая, допустим, досталась тебе с легаси кодом, ты не можешь. Нет абсолютно никаких гарантий, что она актуальна, и вообще о чем-то.
G>>Что, разумеется, ничерта тебе не поможет. Люди в ветке все правильно говорят — если система большая, то диаграмма не поможет, если маленькая — то она не нужна.
B>Хорошие диаграммы помогают. Но спорить абсттрактно бесполезно.
Диаграмма классов не бывает плохой, или хорошей. Она строится из кода однозначным, механическим образом. Она бывает актуальной (соответствующей коду), и неактуальной. Актуальную ты за пару минут получаешь при помощи Розы, и (о горе) это тебе никак не помогает.
B>Надо брать конкретные примеры и обсуждать, на что естесвенно нету времени.
Тут нечего обсуждать. Либо опыт был, либо его не было.
G>>А я добавлю — ценность не в диаграмме, а в тех процессах, которые происходят у тебя в мозгу, когда ты ее составляешь, ползая по коду. После составления диаграмму можно немедленно порвать — она нафиг не нужна.
G>>И диаграмма классов — наименее ценна их всех моделей. Поток данных куда важнее. Для протоколов — конечные автоматы важнее. Это понимание извлекается только из кода, и глупо пытаться жульничать, избегая с ним контакта. Все равно тебе рано или поздно придется столкнуться с кодом, и ты будешь смотреть на него как баран на новые ворота.
B>Ну слава богу. Хорошо, что хоть признал что есть и другие диаграммы.
Все это время мы говорим о диаграмме классов. Ты читать что написано в ветке — будешь?
G>>Желание "видеть диаграмму", и стенания по поводу отсутствующей документации — симптом кодобоязни.
B>Одно другому не мешает.
Мешает.
B>Огульное отрицание диаграмм — это экстремизм в чистом виде.
Ни в одном месте я не отрицал диаграмм, и тем более не делал это "огульно".
B>Впрочем на этом форуме это совсем не проблема
Точно. Проблема в том, что кое-кто не умеет читать, что написано, и приписывает свои фантазии собеседнику.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, bkat, Вы писали:
G>>>Автогенеренные пауки удаляются сразу. "Любая диаграмма" в Розе строится драг-энж-дропом — бросаешь на чистый лист интересные тебе классы, они сами в диаграмму связываются. После чего — скрываешь на диаграмме с классов те мемберы, которые тебе не интересны — и вуаля. Несколько минут на любую диаграмму классов.
B>>Несколько минут при условии, что ты знаешь, что ты хочешь показать.
G>Все что тебе надо знать — это список классов, который ты хочешь показать. И даже если я тебе перечислю их названия — ты в реальной ситуации ничерта из диаграммы не поймешь. Набросать тебе фрагмент для примера? Вот что такое, по твоему, BarServer и ContractServer? Классы так называются. И что?
G>И доверять диаграмме, которая, допустим, досталась тебе с легаси кодом, ты не можешь. Нет абсолютно никаких гарантий, что она актуальна, и вообще о чем-то.
G>>>Что, разумеется, ничерта тебе не поможет. Люди в ветке все правильно говорят — если система большая, то диаграмма не поможет, если маленькая — то она не нужна.
B>>Хорошие диаграммы помогают. Но спорить абсттрактно бесполезно.
G>Диаграмма классов не бывает плохой, или хорошей. Она строится из кода однозначным, механическим образом. Она бывает актуальной (соответствующей коду), и неактуальной. Актуальную ты за пару минут получаешь при помощи Розы, и (о горе) это тебе никак не помогает.
Плохих диаграмм нету. Есть бесполезные.
Даже точно определив классы не достаточно для полезной диаграммы классов.
Должно быть пояснение что и зачем ты хочешь показать.
Можно скрыть ненужные на данной диаграммы методы и т.п.
Можно сослаться на другие диаграммы (к примеру диаграммы состояний)
которые показывают другие детали.
B>>Надо брать конкретные примеры и обсуждать, на что естесвенно нету времени.
G>Тут нечего обсуждать. Либо опыт был, либо его не было.
Ну у меня есть вполне реальный опыт с большими легаси проектами разрабатываемыми больше 10 лет.
Дальше что?
G>>>А я добавлю — ценность не в диаграмме, а в тех процессах, которые происходят у тебя в мозгу, когда ты ее составляешь, ползая по коду. После составления диаграмму можно немедленно порвать — она нафиг не нужна.
G>>>И диаграмма классов — наименее ценна их всех моделей. Поток данных куда важнее. Для протоколов — конечные автоматы важнее. Это понимание извлекается только из кода, и глупо пытаться жульничать, избегая с ним контакта. Все равно тебе рано или поздно придется столкнуться с кодом, и ты будешь смотреть на него как баран на новые ворота.
B>>Ну слава богу. Хорошо, что хоть признал что есть и другие диаграммы.
G>Все это время мы говорим о диаграмме классов. Ты читать что написано в ветке — будешь?
Ну ты почему-то ограничил обсуждение только обсуждением диаграмм классов.
Не понимаю к чему это ограничение и где в ветке написано что надо обсуждать только то, что ты считаешь относящимся к делу?
G>>>Желание "видеть диаграмму", и стенания по поводу отсутствующей документации — симптом кодобоязни.
B>>Одно другому не мешает.
G>Мешает.
B>>Огульное отрицание диаграмм — это экстремизм в чистом виде.
G>Ни в одном месте я не отрицал диаграмм, и тем более не делал это "огульно".
B>>Впрочем на этом форуме это совсем не проблема
G>Точно. Проблема в том, что кое-кто не умеет читать, что написано, и приписывает свои фантазии собеседнику.
Ладно бог сним.
Конструктива все равно не будет...
Здравствуйте, AlexNek, Вы писали:
TSP>>А UML и автогенерация только инструмент. AN>Нужно только знать какими инструментами и как пользоваться. AN>Можно ведь и исключительно нотепадом пользоваться, просто каждый решает это для себя сам в каждом конкретном случае.
Диаграмма это не "инструмент", а нотация. Язык. Никакой существенной разницы, нарисуешь ты классы квадратиками, или будешь читать их определения в .hpp файлах, по сути, нет, кроме того, что в диаграмме будут убиты комментарии.
Чтобы понять поведение незнакомого кода, надо анализировать этот код, а не заниматься игрой в пятнашки, двигая UML-квадратики.
Не, оно конечно понятно, что в код смотреть страшно. Вот бы какой "инструмент" найти, чтобы не читая кода, понять, как он устроен, правда?
Здравствуйте, Gaperton, Вы писали:
G>Чтобы понять поведение незнакомого кода, надо анализировать этот код, а не заниматься игрой в пятнашки, двигая UML-квадратики.
Понять поведение незнакомого кода значительно проще, если ты имеешь представление об общей структуре оного. "UML-квадратики" в этом очень помогают.
Здравствуйте, bkat, Вы писали:
G>>Диаграмма классов не бывает плохой, или хорошей. Она строится из кода однозначным, механическим образом. Она бывает актуальной (соответствующей коду), и неактуальной. Актуальную ты за пару минут получаешь при помощи Розы, и (о горе) это тебе никак не помогает.
B>Плохих диаграмм нету. Есть бесполезные.
Бесполезны все диаграммы, которые не являются иллюстрацией к объяснениям.
В описываемой топикстартером ситуации нет никаких объяснений, и никакой документации. Есть только код. Ты топик-то перечитай.
А беседовать с тобой "о диаграммах" вне контекста топика мне не интересно.
B>Конструктива все равно не будет...
Здравствуйте, Lloyd, Вы писали:
G>>Чтобы понять поведение незнакомого кода, надо анализировать этот код, а не заниматься игрой в пятнашки, двигая UML-квадратики.
L>Понять поведение незнакомого кода значительно проще, если ты имеешь представление об общей структуре оного. "UML-квадратики" в этом очень помогают.
"Квадратики" не помогают тебе понять общую структуру. Ты можешь свое понимание, когда оно у тебя уже есть, выразить в терминах квадратиков, это да. А когда оно у тебя уже есть — тебе лично с этого никакого толку не будет.
И нет никакого смысла тратить время на создание "сокровища" в виде диаграмм классов, которые при помощи розы строятся за минуту в любой момент. И будут при этом актуальны.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AlexNek, Вы писали:
TSP>>>А UML и автогенерация только инструмент. AN>>Нужно только знать какими инструментами и как пользоваться. AN>>Можно ведь и исключительно нотепадом пользоваться, просто каждый решает это для себя сам в каждом конкретном случае.
G>Диаграмма это не "инструмент", а нотация. Язык.
Я "прочитал" высказывание где то так
"А софт для автогенерация UML только инструмент." G>Никакой существенной разницы, нарисуешь ты классы квадратиками, или будешь читать их определения в .hpp файлах,
Кстати, разница есть и весьма существенная. На первом этапе меня интересуют исключительно взаимосвязи между классами информация об отдельном классе практически не интересует. И взаимосвязи из кода уловить не так уж и просто чисто просмотрев его. G>по сути, нет, кроме того, что в диаграмме будут убиты комментарии.
нафиг не нужны на этапе обзора проекта (имея в виду построчные комменты кода). Потом можно просто просмотреть интересующие части.
G>Чтобы понять поведение незнакомого кода, надо анализировать этот код, а не заниматься игрой в пятнашки, двигая UML-квадратики.
Каждый выбирает свой путь в конкретном случае.
G>Не, оно конечно понятно, что в код смотреть страшно.
Все равно в него смотреть нужно, так что страха быть не может. А вот получить обзор из кода несколько затруднительно. G>Вот бы какой "инструмент" найти, чтобы не читая кода, понять, как он устроен, правда?
Не думаю что можно найти что то одно, изучение проекта достаточно комплексная задача и тут все средства хороши.
Здравствуйте, Gaperton, Вы писали:
G>В описываемой топикстартером ситуации нет никаких объяснений, и никакой документации. Есть только код. Ты топик-то перечитай.
Топик я перечитал.
Это подветка началась вообще с весьма сильного утверждения анонима,
которое не ограничивается диаграммами классов:
Как показывает опыт, ни понимание архитектуры разработчиками, ни вообще ее наличие, не являются необходимыми условиями для успешной разработки программ любой сложности и размера.
Еще цитата:
Про UML и прочее сразу могу сказать, что это просто трата времени.
Проблемы будут все одни и те же — время на UML будет потрачено, и, возможно, много, понимание кода разработчиками от этого не улучшится, разработчикам впадлу будет читать доки, на которые кто-то убил столько времени, а потом эти доки рассинхронизируются с кодом, и на них все забьют, ну и так далее. Проходили все это сто раз.
Если же вернуться к топикстартеру, то если он хочет понять как работает система,
то он будет рисовать картинки.
Возможно это будет настенная живопись. Может это будет наброски на туалетной бумаге.
Но что-то дополнительно к коду обязательно появится.
UML — это стандартный, хорошо известный способ, который конечно же можно игнорировать, но зачем?
Здравствуйте, Gaperton, Вы писали:
L>>Понять поведение незнакомого кода значительно проще, если ты имеешь представление об общей структуре оного. "UML-квадратики" в этом очень помогают.
G>Неужели?
G>"Квадратики" не помогают тебе понять общую структуру. Ты можешь свое понимание, когда оно у тебя уже есть, выразить в терминах квадратиков, это да. А когда оно у тебя уже есть — тебе лично с этого никакого толку не будет.
Т.е. вариант, когда диаграмма есть и написана кем-то другим до тебя у тебя выпал из рассмотрения?
G>И нет никакого смысла тратить время на создание "сокровища" в виде диаграмм классов, которые при помощи розы строятся за минуту в любой момент. И будут при этом актуальны.
За минуту строится треш, а не диаграмма. На создание таких диаграмм действительно тратить время не стоит.
Но построив даже трешевую диаграмму, можно начать с ней играться, перетасовывая туда-сюда "кубики", пытаясь в этой мешанине выискать структуру. С кубиками это делать куда проще, чем исключительно по коду.
Здравствуйте, Gaperton, Вы писали:
G>"Квадратики" не помогают тебе понять общую структуру.
Если тебе лично квадратики не помогают, это не означает, что они не помогают другим.
Мне помогают. Я точно не уникум.
Код, кстати, я пишу и читаю в большом количестве.
Что со мной будешь делать?
AN>С другой стороны, заказчик проекта не ставит задание разработать успешный продукт, он заказывает конкретный продукт и хочет получить "успешный проект" — разработанный в срок, при запланированных ресурсах, с приемлемым количеством ошибок, удобный в сопровождении/развитии и пр. Мне думается, что непродуманный "спагетти проект" никак не пойдет на звание такого "успешного проекта", что однако не запрещает ему выступать в роли успешного продукта.
Не надо вводить сущностей сверх необходимого. Продукт, проект — все это давно уже научились выражать в финансовом смысле. Если поддержка написанного начинает становиться убыточной — поддержку прекращают, проект закрывают. Вы пишете о том, что в свое время ваш (теперь уже ваш!) проект разрабатывали непродуманно — иными словами, работали в ущерб качеству, увеличивая другие показатели (например, брали разработчиков подешевле, и требовали от них работать побыстрее). Видимо, в тот момент компромисс был именно таким. Сейчас компромисс другой — проект, видимо, перестал приносить достаточно прибыли и его скинули вам на поддержку (возможно, еще более удешевив). На что вы жалуетесь?
SD>>Более того, сами правки станут значительно более быстрыми. Поверьте, всякие там TDD не на пустом месте возникли. AN>Весьма тяжело это представить. Это что то типа алгоритма как из Г. сделать конфетку?
Это, скорее, алгоритм, рекомендующий завернуть какашку в пакетик, чтобы при переноске до места утилизации не испачкаться и не провонять. Для вас сейчас существующая система — "черный ящик", поскольку вы вряд ли осилите понять 120 человеко-лет какокода. Если осилите — значит, код-то неплох!
Вот и обложите ее тестами так, чтоб можно было относительно смело вносить правки. Может даже и рефакторить. Кто знает, вдруг вы проект оживите.
SD>>Здорово! В принципе, вы могли бы эту "картинку" получить от первоначальных разработчиков. Просто попросили бы объяснить. Вам бы нарисовали, на доске ли, или на бумажке. AN>Для это нужно как минимум иметь подобную возможность.
Вас не пущают к изначальным разработчикам? Плохо. Самому понять чужую логику 10-летней давности редко когда получается. Может, попробуете договориться с начальством, чтобы вам, к примеру, выделяли хотя бы 2-4 часа в неделю на интервью с теми разработчиками?
Здравствуйте, SkyDance, Вы писали:
AN>>С другой стороны, заказчик проекта не ставит задание разработать успешный продукт, он заказывает конкретный продукт и хочет получить "успешный проект" — разработанный в срок, при запланированных ресурсах, с приемлемым количеством ошибок, удобный в сопровождении/развитии и пр. Мне думается, что непродуманный "спагетти проект" никак не пойдет на звание такого "успешного проекта", что однако не запрещает ему выступать в роли успешного продукта.
SD>Не надо вводить сущностей сверх необходимого.
с одной у меня ничего не получается. Я не ограничиваюсь простыми исключительно софт. продуктами. SD>Продукт, проект — все это давно уже научились выражать в финансовом смысле. Если поддержка написанного начинает становиться убыточной — поддержку прекращают, проект закрывают.
Не обязательно, продукт может быть успешным, а поддержка софта слишком дорогой SD>Вы пишете о том,
Вы точно помните что я это писал? SD> что в свое время ваш (теперь уже ваш!) проект разрабатывали непродуманно — иными словами, работали в ущерб качеству, увеличивая другие показатели (например, брали разработчиков подешевле, и требовали от них работать побыстрее). Видимо, в тот момент компромисс был именно таким. Сейчас компромисс другой — проект, видимо, перестал приносить достаточно прибыли и его скинули вам на поддержку (возможно, еще более удешевив). На что вы жалуетесь?
Мне кажется, Вы меня с кем то путаете.
SD>>>Более того, сами правки станут значительно более быстрыми. Поверьте, всякие там TDD не на пустом месте возникли. AN>>Весьма тяжело это представить. Это что то типа алгоритма как из Г. сделать конфетку?
SD>Это, скорее, алгоритм, рекомендующий завернуть какашку в пакетик, чтобы при переноске до места утилизации не испачкаться и не провонять. Для вас сейчас существующая система — "черный ящик", поскольку вы вряд ли осилите понять 120 человеко-лет какокода. Если осилите — значит, код-то неплох! SD>Вот и обложите ее тестами так, чтоб можно было относительно смело вносить правки.
и сколько понадобится тестов на 120 человеко-лет какокода?
Но мне непонятно как написание теста ускоряет правку кода. Видимо тут у нас опять разные понятия. SD> Может даже и рефакторить. Кто знает, вдруг вы проект оживите.
Ну разве что действие будет происходить в голливудском фильме. SD>>>Здорово! В принципе, вы могли бы эту "картинку" получить от первоначальных разработчиков. Просто попросили бы объяснить. Вам бы нарисовали, на доске ли, или на бумажке. AN>>Для это нужно как минимум иметь подобную возможность.
SD>Вас не пущают к изначальным разработчикам? Плохо.
Часто их просто уже нет в доступности. SD>Самому понять чужую логику 10-летней давности редко когда получается. Может, попробуете договориться с начальством, чтобы вам, к примеру, выделяли хотя бы 2-4 часа в неделю на интервью с теми разработчиками?
И кстати, вопрос задавал не я, мне договарится не к чему.
Здравствуйте, bkat, Вы писали:
B>Если же вернуться к топикстартеру, то если он хочет понять как работает система, B>то он будет рисовать картинки.
Много раз приходилось разбираться в коде проектов разной сложности. Ни разу картинки не рисовал.
В моем представлении, картинка — это всегда иллюстрация к самодостаточному объяснению, для кристаллизации мысли.
Если вы из одной лишь картинки можете все понять, 100% вы сможете это понять и без картинки.
А что касается проектов огромных, то я ни разу не видел, чтобы кто-нибудь взял вот так и, с кондачка, накорябав пару картинок, разобрался во всем коде. В больших проектах разбираются постепенно, иногда годами.
А зачем, собственно, разбираться во всем сразу-то? Чтобы пофиксить конкретный баг, достаточно разобраться в небольшой конкретной части кода. По мере работы над конкретными задачами и приходит знание всего кода.
А вы думаете, каждый из тех, кто над этим проектом работал, знал весь код? Скорее всего, каждый программист имел представление лишь о частях, над которыми он лично работал.
Да это глупо даже, на мой взгляд, так задачу формулировать. Вот вам проект, над которым 12-14 человек работали 10 лет. Разберитесь в нем во всем! Ха.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, bkat, Вы писали:
B>>Если же вернуться к топикстартеру, то если он хочет понять как работает система, B>>то он будет рисовать картинки.
А>Много раз приходилось разбираться в коде проектов разной сложности. Ни разу картинки не рисовал.
Я рисовал и делаю это постоянно. Мне лично нарисованные мною картинки действительно ничего нового не дают,
поскольку внятную диаграмму я могу нарисовать только когда понимаю, как работает система.
Нарисованная диаграмма экономит время и силы коллегам.
Проверенно многократно.
Картинки рисуешь не для себя. Картинки — это средство коммуникации.
Если нет необходимости делиться знаниями с другими, то конечно ничего рисовать не нужно.
Но картинки рисуют не только чтобы понять как работает уже готовая система.
Разработка нового кода — это оффтопик, но именно при разработке картинки весьма и весьма полезны.
вы не понимаете в данный момент пользователей, не чувствуете их потребностей и следовательно все ваши действия будут бестолковыми и ненужными
забудьте на полгода-год о юнит-тестах, рефакторинге и прочей дребедени. Вы не знаете пользователей -> не знаете что и как тестировать, -> не знаете как улучшать продукт.
Сейчас вы можете только поддерживать то что есть, фиксить баги.
Через пол года окажется что код не такое уж и говно как казалось поначалу, а кривенькая архитктура таки есть
У тебя взаимоисключающие параграфы.
B>поскольку внятную диаграмму я могу нарисовать только когда понимаю, как работает система.
Здесь ты все правильно говоришь, и, что характерно, именно это тебе объясняли выше по ветке — в частности я. Как и остальное — про то, что диаграммы не более чем иллюстративный материал к объяснениям, и обладают нулевой самостоятельной ценностью.
B>Но картинки рисуют не только чтобы понять как работает уже готовая система.
А вот с этого момента интересно. Ты бодро сам себе возражаешь. "Но" значит "нет". И действительно — здесь пресуппозиция (скрытое предположение), что "картинки" в частности рисуют для того, чтобы понять, как работает уже готова система.
Видишь указанное мной противоречие? Наверное, ты не видишь в этом проблем, не так ли?
А вот мне при таком уровне аргументации разговаривать не о чем. Не интересно.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, bkat, Вы писали:
G>У тебя взаимоисключающие параграфы.
B>>поскольку внятную диаграмму я могу нарисовать только когда понимаю, как работает система.
G>Здесь ты все правильно говоришь, и, что характерно, именно это тебе объясняли выше по ветке — в частности я. Как и остальное — про то, что диаграммы не более чем иллюстративный материал к объяснениям, и обладают нулевой самостоятельной ценностью.
B>>Но картинки рисуют не только чтобы понять как работает уже готовая система.
G>А вот с этого момента интересно. Ты бодро сам себе возражаешь. "Но" значит "нет". И действительно — здесь пресуппозиция (скрытое предположение), что "картинки" в частности рисуют для того, чтобы понять, как работает уже готова система.
До сих пор мне приходилось и приходится работать в команде.
"Понять как работает система" — это не про меня лично, а про команду.
Топикстартер тоже кстати, говорит о трех девелоперах, которым дали систему на поддержку.
Можно конечно разобраться с кусом кода, а сук (пардон, коллег) послать читать тот же самый код.
Но можно нарисовать что-то и поделиться сокровенным знанием с коллегами.
G>Видишь указанное мной противоречие? Наверное, ты не видишь в этом проблем, не так ли?
Противоречий не вижу...
Вижу кучу негативной энергии, которая напрочь убивает конструктив.
R>забудьте на полгода-год о юнит-тестах, рефакторинге и прочей дребедени. Вы не знаете пользователей -> не знаете что и как тестировать, -> не знаете как улучшать продукт.
О юнит-тестах может и можно забыть, но хотя бы высокоуровневые тесты и тестовую систему сделайте. Хотя бы какой-никакой continuous integration system введите. В таких больших проектах CI оказывает незаменимую помощь.
Здравствуйте, bkat, Вы писали:
G>>А вот с этого момента интересно. Ты бодро сам себе возражаешь. "Но" значит "нет". И действительно — здесь пресуппозиция (скрытое предположение), что "картинки" в частности рисуют для того, чтобы понять, как работает уже готова система.
B>До сих пор мне приходилось и приходится работать в команде. B>"Понять как работает система" — это не про меня лично, а про команду.
Ты вкладываешь слишком необычный смысл в свои слова, чтобы тебя можно было понять. "Не про тебя лично" звучит совсем по другому — "объяснить, как работает система".
Извини, я не верю, что ты настолько плохо владеешь русским языком. Все-таки, не первый год тебя знаю по форуму. Ты сейчас просто выкручиваешься.
B>Топикстартер тоже кстати, говорит о трех девелоперах, которым дали систему на поддержку.
Не понимаю, в каком месте это "кстати". Хоть три, хоть пять — смысл простых речевых оборотов русского языка от этого меняться не должен.
B>Но можно нарисовать что-то и поделиться сокровенным знанием с коллегами.
Ты выше написал "понять", а не "поделиться". И во всей ветке обсуждалось именно это.
G>>Видишь указанное мной противоречие? Наверное, ты не видишь в этом проблем, не так ли?
B>Противоречий не вижу... B>Вижу кучу негативной энергии, которая напрочь убивает конструктив.
Вот-вот. А я очень сильно не люблю, когда собеседники начинают врать и выкручиваться. Это неуважение к собеседнику. Типо, ты его очень конструктивно за дурачка держишь.
Здравствуйте, AlexNek, Вы писали:
TSP>>>>А UML и автогенерация только инструмент. AN>>>Нужно только знать какими инструментами и как пользоваться. AN>>>Можно ведь и исключительно нотепадом пользоваться, просто каждый решает это для себя сам в каждом конкретном случае.
G>>Диаграмма это не "инструмент", а нотация. Язык. AN>Я "прочитал" высказывание где то так AN>"А софт для автогенерация UML только инструмент."
Софт позволяет тебе сократить время на построение диаграмм. То есть, этот "инструмент" не более, чем немного экономит тебе время на само рисование. И все.
G>>Никакой существенной разницы, нарисуешь ты классы квадратиками, или будешь читать их определения в .hpp файлах, AN>Кстати, разница есть и весьма существенная. На первом этапе меня интересуют исключительно взаимосвязи между классами информация об отдельном классе практически не интересует. И взаимосвязи из кода уловить не так уж и просто чисто просмотрев его.
Простой факт наличия взаимосвязи, выраженный стрелкой на UML-диаграмме, либо наличием указателя в hpp файле (что примерно один хрен), тебе также ничего не даст. Тебе надо знать не это, а какой поток данных идет по каждой из взаимосвязей, что из UML диаграммы вообще вытащить невозможно. И, кстати, в UML в принципе отсутствует нотация для того, чтобы это показать (такая нотация была в диаграммах Буча, если интересно).
Глобально для понимания системы тебе важно знать основной поток данных, который цепочкой своего прохождения и выделяет те немногие "центральные" классы из сотен остальной требухи. Это также может быть извлечено только из кода.
В результате, на первом этапе тебя должны не "связи" интересовать, а вопрос, какие 6-7 из каждой сотни классов являются "центральными". По UML-диаграммам это понять невозможно. Только анализ кода.
G>>по сути, нет, кроме того, что в диаграмме будут убиты комментарии. AN>нафиг не нужны на этапе обзора проекта (имея в виду построчные комменты кода). Потом можно просто просмотреть интересующие части.
Ты лучше комментарии в хедерах имей в виду, где определяются твои классы. Их иногда, в отличии от документации, все-таки пишут.
G>>Чтобы понять поведение незнакомого кода, надо анализировать этот код, а не заниматься игрой в пятнашки, двигая UML-квадратики. AN>Каждый выбирает свой путь в конкретном случае.
Ага. Только некоторые пути ведут в никуда.
G>>Не, оно конечно понятно, что в код смотреть страшно. AN>Все равно в него смотреть нужно, так что страха быть не может. А вот получить обзор из кода несколько затруднительно.
Это просто надо уметь делать. Когда тебе достается легаси-система, не существует никакого другого способа получить обзор, кроме как из кода.
Здравствуйте, bkat, Вы писали:
G>>"Квадратики" не помогают тебе понять общую структуру.
B>Если тебе лично квадратики не помогают, это не означает, что они не помогают другим. B>Мне помогают. Я точно не уникум.
Определенно, уникум. Ибо в структурных моделях, к которым относятся диаграммы классов, объективно слишком мало для этого информации — они не содержат в себе информации ни о времени, ни о функциональной связности. Поэтому, увидев готовую диаграмму классов по не знакомой тебе системе (в которой до кучи названия классов и методов строятся из убогого словаря английских терминов в пару сотен слов, а часть вообще названа неправильно), в реальности ты ничерта по ней не поймешь.
B>Код, кстати, я пишу и читаю в большом количестве. B>Что со мной будешь делать?
Здравствуйте, Gaperton, Вы писали:
B>>Если тебе лично квадратики не помогают, это не означает, что они не помогают другим. B>>Мне помогают. Я точно не уникум.
G>Определенно, уникум. Ибо в структурных моделях, к которым относятся диаграммы классов, объективно слишком мало для этого информации — они не содержат в себе информации ни о времени, ни о функциональной связности. Поэтому, увидев готовую диаграмму классов по не знакомой тебе системе (в которой до кучи названия классов и методов строятся из убогого словаря английских терминов в пару сотен слов, а часть вообще названа неправильно), в реальности ты ничерта по ней не поймешь.
Главное часто-часто это повторять, приправить словами поумнее и писать уверенно, тогда тебе обязательно поверят.
Но только те, кто не пробовал предмет обсуждения на практике.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AlexNek, Вы писали:
TSP>>>>>А UML и автогенерация только инструмент. AN>>>>Нужно только знать какими инструментами и как пользоваться. AN>>>>Можно ведь и исключительно нотепадом пользоваться, просто каждый решает это для себя сам в каждом конкретном случае.
G>>>Диаграмма это не "инструмент", а нотация. Язык. AN>>Я "прочитал" высказывание где то так AN>>"А софт для автогенерация UML только инструмент."
G>Софт позволяет тебе сократить время на построение диаграмм. То есть, этот "инструмент" не более, чем немного экономит тебе время на само рисование. И все.
Ну для меня не все, он мне еще позволяет скажем, "оптимизировать" диаграмму. По крайней мере я нашел несколько "проблем" в текущем проекте. Обрабатываю диаграмму, и смотрю, есть связи которые "мешают" выстроить все "красиво" и точно, они были лишними. (Нежелательная связь модулей)
G>>>Никакой существенной разницы, нарисуешь ты классы квадратиками, или будешь читать их определения в .hpp файлах, AN>>Кстати, разница есть и весьма существенная. На первом этапе меня интересуют исключительно взаимосвязи между классами информация об отдельном классе практически не интересует. И взаимосвязи из кода уловить не так уж и просто чисто просмотрев его.
G>Простой факт наличия взаимосвязи, выраженный стрелкой на UML-диаграмме, либо наличием указателя в hpp файле (что примерно один хрен), тебе также ничего не даст. Тебе надо знать не это, а какой поток данных идет по каждой из взаимосвязей, что из UML диаграммы вообще вытащить невозможно. И, кстати, в UML в принципе отсутствует нотация для того, чтобы это показать (такая нотация была в диаграммах Буча, если интересно).
G>Глобально для понимания системы тебе важно знать основной поток данных, который цепочкой своего прохождения и выделяет те немногие "центральные" классы из сотен остальной требухи. Это также может быть извлечено только из кода.
"Поток данных" я также люблю и рисую его в "Диа" когда нужно объяснить концепт работы. Но простым просмотром кода "выловить его", думаю не получится.
G>В результате, на первом этапе тебя должны не "связи" интересовать, а вопрос, какие 6-7 из каждой сотни классов являются "центральными". По UML-диаграммам это понять невозможно. Только анализ кода.
Я же говорю, у каждого свой подход к разбору проекта. Мне вначале важны именно связи, потому как из них образуются "кластеры". И я не анализирую, что либо исключительно одно. Получили допустим "кластер", смотрим как там внутри него "живут" исходники (принадлежат ли они одному проекту или нескольким и т.п.) Хотя точно все описать видимо не получится.
G>>>по сути, нет, кроме того, что в диаграмме будут убиты комментарии. AN>>нафиг не нужны на этапе обзора проекта (имея в виду построчные комменты кода). Потом можно просто просмотреть интересующие части.
G>Ты лучше комментарии в хедерах имей в виду, где определяются твои классы. Их иногда, в отличии от документации, все-таки пишут.
Мне лично это все-таки попадается настолько редко, что о нем можно и забыть.
G>>>Чтобы понять поведение незнакомого кода, надо анализировать этот код, а не заниматься игрой в пятнашки, двигая UML-квадратики. AN>>Каждый выбирает свой путь в конкретном случае.
G>Ага. Только некоторые пути ведут в никуда.
Это выясняется после первого эксперимента, при этом результаты могут кардинально отличаться для каждого конкретного человека. Один может считать данный путь ошибочным, другому он может быть полезен
G>>>Не, оно конечно понятно, что в код смотреть страшно. AN>>Все равно в него смотреть нужно, так что страха быть не может. А вот получить обзор из кода несколько затруднительно.
G>Это просто надо уметь делать. Когда тебе достается легаси-система, не существует никакого другого способа получить обзор, кроме как из кода.
Для начального этапа мне достаточно глянуть связь модулей. Вот хотя бы как мне из кода это именно все сразу "увидеть"? (Пример взят просто из — за того, что это опен соурсе "под рукой")
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Gaperton, Вы писали:
B>>>Если тебе лично квадратики не помогают, это не означает, что они не помогают другим. B>>>Мне помогают. Я точно не уникум.
G>>Определенно, уникум. Ибо в структурных моделях, к которым относятся диаграммы классов, объективно слишком мало для этого информации — они не содержат в себе информации ни о времени, ни о функциональной связности. Поэтому, увидев готовую диаграмму классов по не знакомой тебе системе (в которой до кучи названия классов и методов строятся из убогого словаря английских терминов в пару сотен слов, а часть вообще названа неправильно), в реальности ты ничерта по ней не поймешь.
L>Главное часто-часто это повторять, приправить словами поумнее и писать уверенно, тогда тебе обязательно поверят. L>Но только те, кто не пробовал предмет обсуждения на практике.
А что делать с теми, кто тоже пробовал и кому помогает?
Происходит примерно так, как описано в "Аквариуме". Из места А посылается определенная радиограмма, а из места Б через 15 минут вылетает бомбардировщик. Если изучать исключительно радиограммы, то это найти практически невозможно, но проведя анализ и систематизацию одного типа информации и другого, вполне можно заметить связи "неизвестные раннее".
Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
AN>Для начального этапа мне достаточно глянуть связь модулей. Вот хотя бы как мне из кода это именно все сразу "увидеть"? (Пример взят просто из — за того, что это опен соурсе "под рукой")
(диаграмма)
Гм, вы меня аж заинтриговали. Что нового и важного открыла вам диаграмма? Какую пользу вы извлекли из нее? Ну, кроме того, что связано все как попало?
Здравствуйте, Lloyd, Вы писали:
G>>Определенно, уникум. Ибо в структурных моделях, к которым относятся диаграммы классов, объективно слишком мало для этого информации — они не содержат в себе информации ни о времени, ни о функциональной связности. Поэтому, увидев готовую диаграмму классов по не знакомой тебе системе (в которой до кучи названия классов и методов строятся из убогого словаря английских терминов в пару сотен слов, а часть вообще названа неправильно), в реальности ты ничерта по ней не поймешь.
L>Главное часто-часто это повторять, приправить словами поумнее и писать уверенно, тогда тебе обязательно поверят. L>Но только те, кто не пробовал предмет обсуждения на практике.
О, я понял сарказм. Ты хочешь сказать, что главное — это делать ровно наоборот. Часто-часто повторять словами поглупее, ссылаясь на собственную таинственную практику, и не забыть перевести разговор с темы на личность собеседника. Это же так интересно, правда Lloyd?
Здравствуйте, AlexNek, Вы писали:
L>>Главное часто-часто это повторять, приправить словами поумнее и писать уверенно, тогда тебе обязательно поверят. L>>Но только те, кто не пробовал предмет обсуждения на практике. AN>А что делать с теми, кто тоже пробовал и кому помогает?
Небольшая поправка. С теми, кто говорит что пробовал и помогает. Очевидно, также ничего делать не надо. "Ты тоже говори" (с).
AN>Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
Здравствуйте, AlexNek, Вы писали:
G>>Софт позволяет тебе сократить время на построение диаграмм. То есть, этот "инструмент" не более, чем немного экономит тебе время на само рисование. И все. AN>Ну для меня не все, он мне еще позволяет скажем, "оптимизировать" диаграмму. По крайней мере я нашел несколько "проблем" в текущем проекте. Обрабатываю диаграмму, и смотрю, есть связи которые "мешают" выстроить все "красиво" и точно, они были лишними. (Нежелательная связь модулей)
Пример такой "проблемы", пожалуйста. Жуть как любопытно.
G>>Глобально для понимания системы тебе важно знать основной поток данных, который цепочкой своего прохождения и выделяет те немногие "центральные" классы из сотен остальной требухи. Это также может быть извлечено только из кода. AN>"Поток данных" я также люблю и рисую его в "Диа" когда нужно объяснить концепт работы. Но простым просмотром кода "выловить его", думаю не получится.
И чем же его можно выловить? Может быть, непростым просмотром кода? Ну не ментальным же сканированием мы его выявлять собираемся?
G>>Это просто надо уметь делать. Когда тебе достается легаси-система, не существует никакого другого способа получить обзор, кроме как из кода. AN>Для начального этапа мне достаточно глянуть связь модулей. Вот хотя бы как мне из кода это именно все сразу "увидеть"? (Пример взят просто из — за того, что это опен соурсе "под рукой")
Зачем тебе надо его "сразу" увидеть? Какой полезный вывод ты из этой паутины делаешь? К какому действию приводит этот охрененски полезный вывод? Может быть, полезный вывод — janus.exe стоит в центре, и начинать надо с него? Я умоляю. Это и без диаграммы ясно.
Здравствуйте, Gaperton, Вы писали:
L>>Главное часто-часто это повторять, приправить словами поумнее и писать уверенно, тогда тебе обязательно поверят. L>>Но только те, кто не пробовал предмет обсуждения на практике.
G>О, я понял сарказм. Ты хочешь сказать, что главное — это делать ровно наоборот. Часто-часто повторять словами поглупее,
Gaperton, ты ж вроде большой и умный уже. Откуда это стремление удариться в крайности?
Противоположность тут не "слова поглупее", а аргументированная точка зрения. От тебя же кроме безосновательных лозунгов ничего не прозвучало.
G>ссылаясь на собственную таинственную практику,
С чего бы она "таинственная"? Или без этого эпитета не сочно звучало?
G>и не забыть перевести разговор с темы на личность собеседника.
А где я переводил на личность собеседника?
G>Это же так интересно, правда Lloyd?
Здравствуйте, Gaperton, Вы писали:
AN>>Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
G>И в чем состоит польза?
Если не возражаешь, я отвечу.
Лично для меня неудобство кода состоит в том, что код содержит слишком много деталей, в отличии от диаграммы. На диаграмме можно набросать только высокоуровневые вещи и уже дальше разбираться как что с чем связано, и как оно все в совокупности работает.
Здравствуйте, SkyDance, Вы писали:
SD> AN>Для начального этапа мне достаточно глянуть связь модулей. Вот хотя бы как мне из кода это именно все сразу "увидеть"? (Пример взят просто из — за того, что это опен соурсе "под рукой")
SD> (диаграмма)
SD> Гм, вы меня аж заинтриговали. Что нового и важного открыла вам диаграмма? Какую пользу вы извлекли из нее? Ну, кроме того, что связано все как попало?
Отвечу подробней позже, сорри.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AlexNek, Вы писали:
L>>>Главное часто-часто это повторять, приправить словами поумнее и писать уверенно, тогда тебе обязательно поверят. L>>>Но только те, кто не пробовал предмет обсуждения на практике. AN>>А что делать с теми, кто тоже пробовал и кому помогает?
G>Небольшая поправка. С теми, кто говорит что пробовал и помогает. Очевидно, также ничего делать не надо. "Ты тоже говори" (с).
Ну я не собираюсь никого ни в чем убеждать Если вы считаете мои высказывания плодом больного воображения — это Ваше право.
AN>>Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
G>И в чем состоит польза?
Если в диаграмме нет порядка, то и в проекте и в коде он также отсутствует либо там просто "не пахнет классовым подходм". По крайней мере, это рабочая гипотеза которую можно подтвердить или опровернуть.
Здравствуйте, SkyDance, Вы писали:
AN>>Для начального этапа мне достаточно глянуть связь модулей. Вот хотя бы как мне из кода это именно все сразу "увидеть"? (Пример взят просто из — за того, что это опен соурсе "под рукой")
SD>(диаграмма)
SD>Гм, вы меня аж заинтриговали. Что нового и важного открыла вам диаграмма? Какую пользу вы извлекли из нее? Ну, кроме того, что связано все как попало?
Для начала уточню, что это просто самая обычная диаграмма, не предназначенная для объяснения чего либо. Но, тем не менее за отсутствием другого будем использовать ее.
Я исхожу их того, что об организации проекта я не знаю практически ничего. Что же мне видно.
— что в проекте имеется 5 исполняемых файлов (хотя можно и по содержимому каталога увидеть). Один из них полностью самостоятельный и самодостаточный. Три используют грид и еще один дополнительно редактор, то есть это что связано с просмотром табличных данных. Один из трех точно наш главный проект, другие получаются вспомогательные.
— Janus.Rsdn-Model отчего то стоит совсем одиноко. Либо она не нужна, либо устарела, либо вызывается как то хитро. (Как оказалось — это константы для аттрибутов и студия их "не заметила")
— Проект поддерживает несколько типов баз данных (это "запрятано" в сером квадратике) которые довольно неплохо изолированы от основного ехе. Базы используются только основным проектом, вспомогательным они не нужны.
— ни один из проектов не имеет связи с базами (связь идет от баз к 4 проектам), значит они подключаются динамически.
— R.SAT-Model может быть библиотекой обшего использования и не предназначаться для конкретного проекта. Как впрочем TreeGrid и ScintillaEditor (Janus.Framework судя по названию общая библиотека для проекта). Это так называемые "концевики". (Определение моё)
— Janus.Model похоже играет так же роль библиотеки для основного проекта. Однако имеет "странные" связи с гридом (надо бы выяснить отчего)
— Janus.Rsdn, Shortcuts не имеют входных связей, также кандидаты на динамическую загрузку.
— lucene.Net и Rsdn.Framework.Formatting являются "изолированными концевиками", там должен находится код общего назначения для которых нужно либо искать юнит тесты либо сразу их делать, не разбираясь во всем остальном.
— GoJanusNet довольно "слабо связан" с основным модулем, требуется видимо не часто и используется в весьма ограниченном количестве мест.
— Проект имеет как бы три группы: "левую"- самую сложную, "верхнюю" и "правую" — относительно простые. То есть на изучение левой группы можно кинуть пару человек, а верх и право можно отдать и одному.
— в проекте не обнаружено "циклических зависимостей". что само по себе уже хорошо.
— На этой диаграмме я забыл включить показ Hubs (top 25% of highly-connected nodes) но это следующие 4: Janus.Rsdn, Janus.Model, Janus.Common, TreeGrid. На их изучение нужно обратить особое внимание.
Изучение отдельных проектов лучше начинать с "концевиков"
Мне эта информация кажется довольно полезной и она также дает векторы направления дальнейших поисков.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AlexNek, Вы писали:
G>>>Софт позволяет тебе сократить время на построение диаграмм. То есть, этот "инструмент" не более, чем немного экономит тебе время на само рисование. И все. AN>>Ну для меня не все, он мне еще позволяет скажем, "оптимизировать" диаграмму. По крайней мере я нашел несколько "проблем" в текущем проекте. Обрабатываю диаграмму, и смотрю, есть связи которые "мешают" выстроить все "красиво" и точно, они были лишними. (Нежелательная связь модулей)
G>Пример такой "проблемы", пожалуйста. Жуть как любопытно.
На диаграмме это связи Janus-Model и PropertyGridCustomizer, TreeGrid. В данном случае они мне непонятны и уменьшают "красоту". Лично я сторонник минимума межмодульных связей. Имея хотя бы одну "случайную" связь можно довольно просто добавить нежелательную связь модулей. Ну например, сейчас у нас есть правило, что плагины и приложение имеют право использовать только библиотеки общего назначения в которых нет синглтонов. (Требуется обеспечить связь исключительно по определенному интерфейсу)
G>>>Глобально для понимания системы тебе важно знать основной поток данных, который цепочкой своего прохождения и выделяет те немногие "центральные" классы из сотен остальной требухи. Это также может быть извлечено только из кода. AN>>"Поток данных" я также люблю и рисую его в "Диа" когда нужно объяснить концепт работы. Но простым просмотром кода "выловить его", думаю не получится.
G>И чем же его можно выловить? G>Может быть, непростым просмотром кода?
Просмотр кода — для меня это просто открытие файла и его визуальный просмотр.
Для выявления потоков данных требуется анализ кода, с решарпером, отладчиком и прочим что есть. При этом асинхронные или много-потоковые операции будет отследить довольно трудно. И перед этим уже нужно знать все ключевые системы. G>Ну не ментальным же сканированием мы его выявлять собираемся?
G>>>Это просто надо уметь делать. Когда тебе достается легаси-система, не существует никакого другого способа получить обзор, кроме как из кода. AN>>Для начального этапа мне достаточно глянуть связь модулей. Вот хотя бы как мне из кода это именно все сразу "увидеть"? (Пример взят просто из — за того, что это опен соурсе "под рукой")
G>Зачем тебе надо его "сразу" увидеть? Какой полезный вывод ты из этой паутины делаешь? К какому действию приводит этот охрененски полезный вывод? Может быть, полезный вывод — janus.exe стоит в центре, и начинать надо с него? Я умоляю. Это и без диаграммы ясно.
Тут еще проблема в том, что мне довольно важно именно увидеть картинку системы, потом она будет просто дополняться и видоизменяться.
А пример того что можно примерно увидеть я уже написал.
Здравствуйте, AlexNek, Вы писали:
G>>Небольшая поправка. С теми, кто говорит что пробовал и помогает. Очевидно, также ничего делать не надо. "Ты тоже говори" (с). AN>Ну я не собираюсь никого ни в чем убеждать Если вы считаете мои высказывания плодом больного воображения — это Ваше право.
Нет, "плодом больного воображения" я их не считаю. Я не Lloyd, эмоциональных оценок чужим высказываниям не выдаю.
AN>>>Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
G>>И в чем состоит польза? AN>Если в диаграмме нет порядка, то и в проекте и в коде он также отсутствует либо там просто "не пахнет классовым подходм". По крайней мере, это рабочая гипотеза которую можно подтвердить или опровернуть.
1) В любом большом "проекте" с длинной историей вы не обнаружите никакого видимого "порядка" в автогенерированной диаграмме. На то есть объективные причины. Это будет означать лишь то, что вы в ней ничего не понимаете.
2) Сама "рабочая гипотеза" об "отсутствии порядка" субъективна и практически бесполезна. Из ее "верности" или "неверности" напрямую не следует никаких полезных действий. А понимание в инженерном деле требуется для действия. И если первым действием будет являться "наведение порядка" в коде, в котором вы плохо разбираетесь, святая обязанность менеджера немедленно дать таким инициативным людям по рукам.
Ибо нефиг совать руки в работающий код без причины, просто потому, что вы его не понимаете. Особенно, если это сложный legacy код.
Здравствуйте, Lloyd, Вы писали:
AN>>>Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
G>>И в чем состоит польза?
L>Если не возражаешь, я отвечу.
L>Лично для меня неудобство кода состоит в том, что код содержит слишком много деталей, в отличии от диаграммы. На диаграмме можно набросать только высокоуровневые вещи и уже дальше разбираться как что с чем связано, и как оно все в совокупности работает.
L>Как видишь, никакой магии.
Вижу, что ты "ответил" не на мой вопрос, а сказал что-то свое, третье. Совершенно вне контекста беседы. Определенно, здесь какая-то магия.
Здравствуйте, AlexNek, Вы писали:
G>>Пример такой "проблемы", пожалуйста. Жуть как любопытно. AN>На диаграмме это связи Janus-Model и PropertyGridCustomizer, TreeGrid. В данном случае они мне непонятны и уменьшают "красоту".
Здравствуйте, Gaperton, Вы писали:
G>>>И в чем состоит польза?
L>>Если не возражаешь, я отвечу.
L>>Лично для меня неудобство кода состоит в том, что код содержит слишком много деталей, в отличии от диаграммы. На диаграмме можно набросать только высокоуровневые вещи и уже дальше разбираться как что с чем связано, и как оно все в совокупности работает.
L>>Как видишь, никакой магии.
G>Вижу, что ты "ответил" не на мой вопрос, а сказал что-то свое, третье. Совершенно вне контекста беседы. Определенно, здесь какая-то магия.
Да нет, я ответил на твой вопрос "в чем состоит польза". Никакой магии.
Здравствуйте, Gaperton, Вы писали:
G>>>Небольшая поправка. С теми, кто говорит что пробовал и помогает. Очевидно, также ничего делать не надо. "Ты тоже говори" (с). AN>>Ну я не собираюсь никого ни в чем убеждать Если вы считаете мои высказывания плодом больного воображения — это Ваше право.
G>Нет, "плодом больного воображения" я их не считаю. Я не Lloyd, эмоциональных оценок чужим высказываниям не выдаю.
Ты смешной. Где ты в моих словах увидел эмоциональные оценки?
Специально перечитал свои посты и не нашел. Можешь ткнуть палцем, чтобы я знал, как делать не стоит?
AN>>>>Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
G>>>И в чем состоит польза? AN>>Если в диаграмме нет порядка, то и в проекте и в коде он также отсутствует либо там просто "не пахнет классовым подходм". По крайней мере, это рабочая гипотеза которую можно подтвердить или опровернуть.
G>1) В любом большом "проекте" с длинной историей вы не обнаружите никакого видимого "порядка" в автогенерированной диаграмме. На то есть объективные причины. Это будет означать лишь то, что вы в ней ничего не понимаете.
Gaperton, а зачем ты подменяешь все время предмет обсуждения (диаграммы), на что-то свое (автогенерированные диаграммы)? В чем поинт?
G>2) Сама "рабочая гипотеза" об "отсутствии порядка" субъективна и практически бесполезна. Из ее "верности" или "неверности" напрямую не следует никаких полезных действий. А понимание в инженерном деле требуется для действия. И если первым действием будет являться "наведение порядка" в коде, в котором вы плохо разбираетесь, святая обязанность менеджера немедленно дать таким инициативным людям по рукам.
G>Ибо нефиг совать руки в работающий код без причины, просто потому, что вы его не понимаете. Особенно, если это сложный legacy код.
Откуда взялся тезис о ""наведение порядка" в коде, в котором вы плохо разбираетесь"? Речь же шла о лучшем понимании кода.
Опять подменяешь предмет обсуждения?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Gaperton, Вы писали:
G>>>>Небольшая поправка. С теми, кто говорит что пробовал и помогает. Очевидно, также ничего делать не надо. "Ты тоже говори" (с). AN>>>Ну я не собираюсь никого ни в чем убеждать Если вы считаете мои высказывания плодом больного воображения — это Ваше право.
G>>Нет, "плодом больного воображения" я их не считаю. Я не Lloyd, эмоциональных оценок чужим высказываниям не выдаю.
L>Ты смешной. Где ты в моих словах увидел эмоциональные оценки?
Например, в этой твоей фразе. Ты только что написал — "ты смешной". Это эмоциональная оценка.
L>Специально перечитал свои посты и не нашел. Можешь ткнуть палцем, чтобы я знал, как делать не стоит?
А ты, Ллойд, реально смешной . Предупреждая твое очередное "непонимание" — слово "эмоциональная" означает, что оценка основана на эмоциях и содержит эмоции, и это вовсе не то же самое, что ты находишься в состоянии, когда готов перегрызть собеседнику глотку. Впрочем, я за тебя ручаться не могу, кто тебя знает.
L>Опять подменяешь предмет обсуждения?
Тебе кажется, ты участвуешь в обсуждении? Я с такими, как ты, всерьез не беседую. На личности переходишь, контекст не держишь, пишешь ерунду. Перечисленного достаточно, чтобы не воспринимать тебя всерьез.
Здравствуйте, Lloyd, Вы писали:
G>>Вижу, что ты "ответил" не на мой вопрос, а сказал что-то свое, третье. Совершенно вне контекста беседы. Определенно, здесь какая-то магия. L>Да нет, я ответил на твой вопрос "в чем состоит польза". Никакой магии.
AN>> Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
G> И в чем состоит польза?
Это слишком сложно, поэтому я объясню. Вопрос звучал: в чем состоит польза от информации, что "построенная мной диаграмма ни о чем не говорит"?
А ты ответил на какой-то другой, одному тебе известный вопрос. Мне очень жаль, Ллойд. Но так как это явление систематическое, я с тобой обычно всерьез и не беседую.
Здравствуйте, Gaperton, Вы писали:
G>>>Нет, "плодом больного воображения" я их не считаю. Я не Lloyd, эмоциональных оценок чужим высказываниям не выдаю.
L>>Ты смешной. Где ты в моих словах увидел эмоциональные оценки?
G>Например, в этой твоей фразе. Ты только что написал — "ты смешной". Это эмоциональная оценка.
Т.е. до этого эмоциональной оценки не было? Не, правда, смешной.
L>>Специально перечитал свои посты и не нашел. Можешь ткнуть палцем, чтобы я знал, как делать не стоит?
G>А ты, Ллойд, реально смешной . Предупреждая твое очередное "непонимание" — слово "эмоциональная" означает, что оценка основана на эмоциях и содержит эмоции, и это вовсе не то же самое, что ты находишься в состоянии, когда готов перегрызть собеседнику глотку. Впрочем, я за тебя ручаться не могу, кто тебя знает.
Спасибо за урок русского языка, но не стоило себя утруждать, что значит "эмоциональный" я знаю и без тебя.
Так ты дашь ссылку на пост, который по твоему мнению основан или содержит эмоции?
Я даже знаю, какой ответ ты дашь. Ты обыграешь "не стоили утруждать" и опять уйдешь от ответа. Правда ведь, Gaperton?
L>>Опять подменяешь предмет обсуждения?
G>Тебе кажется, ты участвуешь в обсуждении? Я с такими, как ты, всерьез не беседую. На личности переходишь, контекст не держишь, пишешь ерунду. Перечисленного достаточно, чтобы не воспринимать тебя всерьез.
Нет, перечисленного недостаточно. Все перечисленное — твои фантазии, не более того. Пока что переходишь на личности и не держишь контекст тут только ты.
AN>>> Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
G>> И в чем состоит польза?
G>Это слишком сложно, поэтому я объясню. Вопрос звучал: в чем состоит польза от информации, что "построенная мной диаграмма ни о чем не говорит"?
G>А ты ответил на какой-то другой, одному тебе известный вопрос. Мне очень жаль, Ллойд. Но так как это явление систематическое, я с тобой обычно всерьез и не беседую.
А ты постарайся, Gaperton, и подумай. Не пиши, не играй на эмоциях, не переходи на личности, не оскорбляй собеседника, а просто сядь и в спокойной обстановке подумай. Тогда наверняка поймешь, в чем именно польза.
Твое истеричное хамство мне уже надоело, куда только смотрят модераторы?
Здравствуйте, Lloyd, Вы писали:
L>Я даже знаю, какой ответ ты дашь. Ты обыграешь "не стоили утруждать" и опять уйдешь от ответа. Правда ведь, Gaperton?
Извини, Ллойд. У тебя не получится обманом заставить меня перечитывать твои комменты.
Даже если ты будешь пытаться по детски брать меня "на слабо". Реально, слабо, ибо зело скучно. Трата времени.
Здравствуйте, rm822, Вы писали:
R>вы не понимаете в данный момент пользователей, не чувствуете их потребностей и следовательно все ваши действия будут бестолковыми и ненужными
А откуда уверенность, что пользователи знают, чего они хотят?
Здравствуйте, Gaperton, Вы писали:
L>>Я даже знаю, какой ответ ты дашь. Ты обыграешь "не стоили утруждать" и опять уйдешь от ответа. Правда ведь, Gaperton?
G>Извини, Ллойд. У тебя не получится обманом заставить меня перечитывать твои комменты.
Извиняю, Gaperton. Покойся с миром.
G>Даже если ты будешь пытаться по детски брать меня "на слабо". Реально, слабо, ибо зело скучно. Трата времени.
Тебе слабо не потому что скучно, а потому что сказать тебе нечего. Иначе бы ответил "по существу вопроса" и не разводил бы эту "трату времени" на два десятка постов.
Здравствуйте, Lloyd, Вы писали:
G>>А ты ответил на какой-то другой, одному тебе известный вопрос. Мне очень жаль, Ллойд. Но так как это явление систематическое, я с тобой обычно всерьез и не беседую.
L>А ты постарайся, Gaperton, и подумай. Не пиши, не играй на эмоциях, не переходи на личности, не оскорбляй собеседника, а просто сядь и в спокойной обстановке подумай. Тогда наверняка поймешь, в чем именно польза.
Давай поступим проще. Давай я буду людей спрашивать, они мне будут отвечать, а ты не будешь мне мешать с людьми беседовать? А если уж встреваешь, то будешь читать, о чем разговор идет? Это такая невыполнимая просьба, Ллойд?
L>Твое истеричное хамство мне уже надоело, куда только смотрят модераторы?
Я говорю, что всерьез с тобой не беседую, потому, что ты не держишь контекст дискуссии.
Я показал тебе, чем отличается мой вопрос от того, на который ответил ты.
И я не понимаю, какого черта ты ко мне из раза в раз назойливо пристаешь. Ты видишь где-то здесь "истерическое хамство"? Жалуйся модераторам.
Здравствуйте, Lloyd, Вы писали:
G>>Даже если ты будешь пытаться по детски брать меня "на слабо". Реально, слабо, ибо зело скучно. Трата времени.
L>Тебе слабо не потому что скучно, а потому что сказать тебе нечего. Иначе бы ответил "по существу вопроса" и не разводил бы эту "трату времени" на два десятка постов.
Ллойд, мне не интересно обсуждать ни твою, ни свою личность. Не вижу в этом никакого интересного "существа вопроса".
Здравствуйте, Gaperton, Вы писали:
G>>>А ты ответил на какой-то другой, одному тебе известный вопрос. Мне очень жаль, Ллойд. Но так как это явление систематическое, я с тобой обычно всерьез и не беседую.
L>>А ты постарайся, Gaperton, и подумай. Не пиши, не играй на эмоциях, не переходи на личности, не оскорбляй собеседника, а просто сядь и в спокойной обстановке подумай. Тогда наверняка поймешь, в чем именно польза.
G>Давай поступим проще. Давай я буду людей спрашивать, они мне будут отвечать, а ты не будешь мне мешать с людьми беседовать? А если уж встреваешь, то будешь читать, о чем разговор идет? Это такая невыполнимая просьба, Ллойд?
Не, Gaperton, не так не пойдет. Мне тогда и тебя придется попросить поступать так же, а я знаю, что это не в твоих силах.
G>И я не понимаю, какого черта ты ко мне из раза в раз назойливо пристаешь.
А я не к тебе пристаю, а к тем, кто пишет что-то, что звучит мягко говоря сомнительно. Так уж получилось, что я не согласен с твоим утверждение о не нужности диаграмм, потому и "пристал".
Когда ты пишешь что-то, что вполне вяжется с моими представленими, я не пристаю.
G>Ты видишь где-то здесь "истерическое хамство"? Жалуйся модераторам.
И что они сделают? Забанят? Нафик такое счастье, я себе не враг, ты и полезного много пишешь.
Здравствуйте, Gaperton, Вы писали:
G>>>Даже если ты будешь пытаться по детски брать меня "на слабо". Реально, слабо, ибо зело скучно. Трата времени.
L>>Тебе слабо не потому что скучно, а потому что сказать тебе нечего. Иначе бы ответил "по существу вопроса" и не разводил бы эту "трату времени" на два десятка постов.
G>Ллойд, мне не интересно обсуждать ни твою, ни свою личность. Не вижу в этом никакого интересного "существа вопроса".
Gaperton, так зачем же ты раз за разом переводишь разговор не обсуждение личности, если тебе не интересно?
Здравствуйте, 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. И вот смотрю на одном листое как — то "некрасиво", цвет базового класса не такой как у всех, а на другом есть базовый класс без наследников. Начал рыть дальше. Оказалось что в двух проектах есть классы с одинаковыми именами. Один, в правильном месте, уже не используется. Другой, который используется должен, по идее быть в другом месте. В принципе мелочь, но нежелательно, "портить красоту". Нужно хотя бы неиспользуемый убрать, а то может ерунда получится.
Здравствуйте, 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. И вот смотрю на одном листое как — то "некрасиво", цвет базового класса не такой как у всех, а на другом есть базовый класс без наследников. Начал рыть дальше. Оказалось что в двух проектах есть классы с одинаковыми именами. Один, в правильном месте, уже не используется. Другой, который используется должен, по идее быть в другом месте. В принципе мелочь, но нежелательно, "портить красоту". Нужно хотя бы неиспользуемый убрать, а то может ерунда получится.
Такими примерами ты дискредитируешь саму идею построения диаграмм. Ну, не используемый класс, ну, в другом месте, да он там ещё сто лет никому нужен бы не был, ан нет, вот понадобилось шефу малярное искусство... Зазеркалье какое-то, право слово.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, AlexNek, Вы писали:
AN>>Вот буквально сегодня нашел проблемку в проекте. Захотел шеф классы на диаграмме разкрасить по принадлежности к под-проектам.
ГВ>Это, наверное, был очень большой шеф, которому понадобилось сделать презентацию инвесторам.
Все абсолютно наоборот Шеф "маленький" диаграмма для внутреннего использования. ГВ> А инвесторы — не иначе, как программисты со стажем, у которых мозги ещё не проветрились после вакханалии ООП. Иначе я с очень большим трудом понимаю, на кой такие художества — заняться больше нечем?
В данном конкретном случае, смысл есть. Есть классы принадлежащие конкретной области 1, есть принадлежащие области 2 и есть еще общие классы на которых базируется 1 и 2. (Ну упрощенно немного). И сразу по цвету, ничего не описывая и говоря можно например сказать, что эти классы принадлежат исключительно области 1. Поэтому делая изменения в этой области, нет риска затронуть остальные области. А если будут изменения в общей области, то нужно обязательно планировать тестирование и 1 и 2.
AN>>В данном случае, для диаграммы классов, были выбраны строго определенные классы, которые могут принадлежать только к одному из 4-х под-проектов. Получилось листов 10. И вот смотрю на одном листое как — то "некрасиво", цвет базового класса не такой как у всех, а на другом есть базовый класс без наследников. Начал рыть дальше. Оказалось что в двух проектах есть классы с одинаковыми именами. Один, в правильном месте, уже не используется. Другой, который используется должен, по идее быть в другом месте. В принципе мелочь, но нежелательно, "портить красоту". Нужно хотя бы неиспользуемый убрать, а то может ерунда получится.
ГВ>Такими примерами ты дискредитируешь саму идею построения диаграмм. Ну, не используемый класс, ну, в другом месте, да он там ещё сто лет никому нужен бы не был
Любая зазубринка на шестеренке когда либо может вылезти боком, поэтому увидев зазубринку можно ее либо записать в реестр зазубринок, либо исправить.
Вот кстати, еще недавний пример. Где то год назад было решено переимовать одну ДЛЛ-ку (всего-то в конце "s" убрать). Namespace за неимением тогда времени решили оставить как есть, фигня ведь мелочь. А в один прекрасный день, в одном из проектов перестали грузится ресурсы. В итоге оказалось, что некто сделал "правильное" имя без "s". Ладно, исправили все как нужно, но теперь система CI отказалась бильдить проект, так как один из тестеров нацепил дополнительные тесты, а сам оказался в это время в отпуске. Не подсчитывал специально, но время исправления той "мелочи" было бы точно гораздо меньше исправления последствий.
Ладно, можно было оставить это класс мертвяком. Но обязательно когда — то кто-то найдется, кто захочет его использовать. Так зачем доводить до этого, когда проще убрать его сейчас. Специально это обычно не ищется, но если что попутно замечаешь, лучше не игнорировать.
ГВ>, ан нет, вот понадобилось шефу малярное искусство... Зазеркалье какое-то, право слово.
А что стоит то выделить нужные классы и изменить им цвет, да практически ничего. А польза есть.
Да если кто еще плакат МФС помнит — там тоже классы были цветными, весьма удобно.
У меня к тебе пара вопросов.
AN>>>Вот буквально сегодня нашел проблемку в проекте. Захотел шеф классы на диаграмме разкрасить по принадлежности к под-проектам.
ГВ>>Это, наверное, был очень большой шеф, которому понадобилось сделать презентацию инвесторам. AN>Все абсолютно наоборот Шеф "маленький" диаграмма для внутреннего использования.
Для какого именно использования?
ГВ>> А инвесторы — не иначе, как программисты со стажем, у которых мозги ещё не проветрились после вакханалии ООП. Иначе я с очень большим трудом понимаю, на кой такие художества — заняться больше нечем? AN>В данном конкретном случае, смысл есть. Есть классы принадлежащие конкретной области 1, есть принадлежащие области 2 и есть еще общие классы на которых базируется 1 и 2. (Ну упрощенно немного). И сразу по цвету, ничего не описывая и говоря можно например сказать, что эти классы принадлежат исключительно области 1. Поэтому делая изменения в этой области, нет риска затронуть остальные области. А если будут изменения в общей области, то нужно обязательно планировать тестирование и 1 и 2.
А у вас, что, нет подобных описаний в словесном виде?
AN>>>В данном случае, для диаграммы классов, были выбраны строго определенные классы, которые могут принадлежать только к одному из 4-х под-проектов. Получилось листов 10. И вот смотрю на одном листое как — то "некрасиво", цвет базового класса не такой как у всех, а на другом есть базовый класс без наследников. Начал рыть дальше. Оказалось что в двух проектах есть классы с одинаковыми именами. Один, в правильном месте, уже не используется. Другой, который используется должен, по идее быть в другом месте. В принципе мелочь, но нежелательно, "портить красоту". Нужно хотя бы неиспользуемый убрать, а то может ерунда получится.
ГВ>>Такими примерами ты дискредитируешь саму идею построения диаграмм. Ну, не используемый класс, ну, в другом месте, да он там ещё сто лет никому нужен бы не был AN>Любая зазубринка на шестеренке когда либо может вылезти боком, поэтому увидев зазубринку можно ее либо записать в реестр зазубринок, либо исправить.
Ты не находишь, что в этом и предыдущем твоём абзаце слишком много "можно" и ни одного "нужно"?
AN>Вот кстати, еще недавний пример. Где то год назад было решено переимовать одну ДЛЛ-ку (всего-то в конце "s" убрать). Namespace за неимением тогда времени решили оставить как есть, фигня ведь мелочь. А в один прекрасный день, в одном из проектов перестали грузится ресурсы. В итоге оказалось, что некто сделал "правильное" имя без "s". Ладно, исправили все как нужно, но теперь система CI отказалась бильдить проект, так как один из тестеров нацепил дополнительные тесты, а сам оказался в это время в отпуске. Не подсчитывал специально, но время исправления той "мелочи" было бы точно гораздо меньше исправления последствий. AN>Ладно, можно было оставить это класс мертвяком. Но обязательно когда — то кто-то найдется, кто захочет его использовать. Так зачем доводить до этого, когда проще убрать его сейчас. Специально это обычно не ищется, но если что попутно замечаешь, лучше не игнорировать.
То есть штатного code review у вас нет?
ГВ>>, ан нет, вот понадобилось шефу малярное искусство... Зазеркалье какое-то, право слово. AN>А что стоит то выделить нужные классы и изменить им цвет, да практически ничего. А польза есть.
Это стоит очень много, если учесть необходимость покупки Розы. Плюс потери времени, плюс ещё много чего.
AN>Да если кто еще плакат МФС помнит — там тоже классы были цветными, весьма удобно.
Ни фига оно не удобно — всё равно названия классов читать приходится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, 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-летним легаси).
Предлагаю отделить данную ветку и вынести куда-либо, например под заголовком "UML-Неправильные и правильные подходы"
Предложения и идеи принимаются в ответах. Флуд будет нещадно сноситься
... << RSDN@Home 1.2.0 alpha 5 rev. 1538>>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Я не ограничиваюсь простыми исключительно софт. продуктами.
А надо?
Может быть, непростым просмотром кода? Ну не ментальным же сканированием мы его выявлять собираемся? 
