Здравствуйте, 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 — это стандартный, хорошо известный способ, который конечно же можно игнорировать, но зачем?
