Вы уже придумали самое важное слово: общение
Не только с другими, но и с вашим будущим я.Если вы напишите заявление сейчас и вернетесь к нему после нескольких месяцев паузы, вам будет нелегко обойтись.Конечно, это зависит от размера и сложности рассматриваемого приложения.Но наличие некоторого визуального представления всегда будет полезно.
Кроме того, схематическое представление приложения перед фактической разработкой - отличный способ обернуть все вокруг.Обычно в вашей первоначальной идее вы обнаруживаете проблемы, которые легко устранить на этом этапе.И, как уже было сказано, эти диаграммы станут полезными в будущем.
Показ других о том, как приложение работает внутри, также важно.У каждого свой подход к решению проблем.Так что что-то интуитивное для вас может показаться странным в глазах другого человека.Это затрудняет понимание концепций приложения, написанного кем-то другим.
Также помните, что лишь немногие из нас (это вообще) пишут идеальный код и делают идеальную архитектуру.Мы люди, мы совершаем ошибки.
Скажем, к примеру, что есть этот отличный шаблон дизайна, который вы слышали о "декораторе", и вы хотите его использовать.Естественно, слово «декоратор» появится в вашем коде, и люди, читающие его, подумают: «Эй, я знаю этот шаблон. Не нужно читать подробности. Я просто буду обращаться с ним как с черным ящиком и использовать его».«.Но что, если вы неверно истолковали шаблон и неправильно его реализовали.Теперь человек, использующий его в качестве черного ящика, столкнется с проблемами.Они могут варьироваться от небольших ошибок до некомпилируемых API-вызовов.Если у вас есть диаграмма всего этого, вам будет гораздо легче точно определить причину.
Самая большая проблема моделирования - это синхронизация диаграмм с вашим кодом.В течение срока службы проекта вы будете вносить изменения.Маленькие и большие.В идеальном мире вы обновляете диаграммы, думаете об этом, позволяете им проникнуть в ваш мозг и , а затем реализуете их.Но мир вряд ли идеален.Таким образом, вы можете в конечном итоге реализовать что-то до его схематического представления (если это вообще-то было схематично).Весь этот процесс громоздок.Будь то потому, что используемое вами программное обеспечение для диаграмм дерьмо или просто из-за нехватки времени.
Лично мне нравится создавать начальную диаграмму.И как только я доволен этим, я погружаюсь в реализацию.Я не буду пересматривать диаграмму для небольших изменений.Да, через некоторое время код будет отклоняться от диаграммы, но Большая Картина все еще там.Если мне нужно будет внести более значительные изменения в архитектуру, я обязательно вернусь к диаграмме.
Что я и сделаю , тем не менее, это поддержание актуальности документации в коде.Большинство инструментов для извлечения документации (например, javadoc) дают вам возможность использовать разметку, которая полезна, чтобы сделать сгенерированные документы удобочитаемыми и удобными для использования.Особенно при использовании гиперссылок.
Итак, возвращаясь к одному из ваших вопросов, где вы спрашиваете, какова выгода в повседневной жизни разработчика, я думаю, что большие диаграммы не имеют большого значения в этом.Просто потому, что, как только вы поймете концепции проекта, вам больше не понадобится диаграмма, поскольку вы ежедневно просматриваете кодовую базу.Что пригодится, хотя это правильные строки документации кода.Прежде всего потому, что многие IDE отображают их во время кодирования или, по крайней мере, облегчают переход к ним.С диаграммами это не так.
Диаграммы, однако, полезны для быстрого начала работы с проектом.
Еще одна мысль о блок-схемах / диаграммах действий: я нахожу это в основномбесполезный. за исключением для сложных алгоритмов, так как это помогает вам визуализировать цикломатическую сложность.Но, честно говоря, мне никогда не приходилось писать сложный алгоритм самостоятельно.Я всегда находил готовую к использованию реализацию либо в стандартной библиотеке, либо в сторонней библиотеке.
И последнее замечание: этот вопрос должен был быть размещен на https://softwareengineering.stackexchange.com/;)