В отдел передали на поддержку и доработку большой проект (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 диаграммы рисуют взглядом, а баги фиксятся сами до того, как они сядут за компьютер.
