Является ли документ описания архитектуры нарушением принципа СУХОЙ?

11

Принцип СУХОГО (не повторяй себя) гласит, что «каждое знание должно иметь одно, однозначное, авторитетное представление в системе». В большинстве случаев это относится к коду, но часто оно распространяется и на документацию.

Говорят, что каждая программная система имеет архитектуру независимо от того, выбрали вы ее или нет. Другими словами, программное обеспечение, которое вы создаете, имеет структуру, и эта структура «как построено» является архитектурой программного обеспечения. Поскольку встроенная программная система поставляется с архитектурой, является ли описание архитектуры этой системы нарушением принципа СУХОЙ? В конце концов, если вам нужно знать архитектуру, вы всегда можете просто посмотреть на код ...

— Майкл
источник

Вы действительно верите, что можете различить архитектуру, взглянув на код? Код расскажет вам все функциональные и нефункциональные требования, архитектурные компромиссы, проблемы развертывания, бизнес-контекст, сценарии использования и т. Д., И т. Д.? Если вы пишете код, можете ДЕЙСТВИТЕЛЬНО сказать вам, что это чертовски тривиальная система.

— luis.espinal

@ luis.espinal, статические и динамические структуры можно отличить от кода и работающей системы соответственно. Будь эти структуры эквивалентны архитектуре системы, будет зависеть от вашей школы мысли. Как вы указали, вам все еще не хватает некоторых больших кусков, включая любые архитектурные драйверы и обоснование проектных решений.

— Майкл

Какая истинная школа мысли приравнивает структуры, производные кода, к архитектуре системы? Если мы знаем, что нам будет не хватать больших кусков, включая любые архитектурные драйверы, то мы упустим всю архитектуру. Это тривиально доказывает, что статические и динамические структуры, которые можно выделить из одного кода, не представляют всю архитектуру (независимо от школы мысли). Если мы посмотрим на довольно хорошо разработанные определения систем и архитектуры программного обеспечения (то есть SEI или INCOSE), они ясны в том, что код является лишь частью архитектуры.

— luis.espinal

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

— luis.espinal

1

@ luis.espinal, предлагаю пригласить вас ответить на этот вопрос! Звучит так, будто вы привели отличную перспективу, которая, я думаю, добавила бы реальную ценность этой теме. Вы проповедуете хору об этом, так почему бы не создать ответ, который полностью объясняет ваше мышление, чтобы каждый мог получить пользу? Вот почему я задал вопрос в первую очередь.

— Майкл

11

Дублирование ваших мыслей в код нарушает принцип СУХОГО?

Боже, если бы вы могли просто узнать архитектуру, изучая код, в первую очередь не было бы таких вещей, как «документы описания архитектуры». Это не повторение, это другой уровень описания системы , который не может быть тривиально выведен из кода, и наоборот. Так что он имеет полное право на существование, даже если вы принимаете DRY.

— П Швед
источник

7

Не принимайте СУХОЕ как жесткое и быстрое правило. Это хорошо, но вы можете только приблизиться к этому на практике.

Также я думаю, что это не очень хорошо написано. «Не повторяйся», по-видимому, не охватывает столь же важный случай, что для внесения семантического или функционального изменения вам придется редактировать исходный текст в нескольких местах, говоря разные, но скоординированные вещи.

Вместо того, чтобы воспринимать это как заповедь не нарушать, лучше понять, почему это хорошая идея, и сделать разумный выбор по этому поводу. Причина, по которой плохо вносить согласованные изменения в нескольких местах, состоит в том, что вы, редактор, допускаете ошибки. Вы не на 100% надежны, чтобы внести изменения без ошибок. Если вам нужно сделать 10 различных исходных текстовых изменений, и вы правильно сделаете только 9 из них, вы допустили ошибку . Вот почему организация исходного текста для минимизации количества согласованных изменений - это хорошо. Это минимизирует ошибки.

Мы не принадлежим к религии, в которой СУХОЙ является одной из заповедей. Это просто удобный, хотя и немного вводящий в заблуждение, способ заключить в себе какой-то здравый смысл.

— Майк Данлавей
источник

4

Описание архитектуры, или Software Design Описание делает нарушают DRY. Однако в большой организации, где проекты последних лет приходят и уходят разработчики, а система слишком велика для того, чтобы один человек мог держать все детали в голове, это критически важный документ. Количество «повторений», необходимое для синхронизации, полностью оправдывает усилия, которые оно экономит при следующем обновлении или обслуживании.

— AShelly
источник

1

Это недоразумение или слепое применение СУХОГО. Архитектурное описание не является нарушением этого. Если кто-то слепо применяет DRY таким образом, то все, кроме кода, является его нарушением ... и, очевидно, это не было целью тех, кто придумал идею этого.

— luis.espinal

2

Описание архитектуры не нарушает принцип DRY.

Ваша программная система поставляется с архитектурой, конечно. И это распределено по многим файлам, во многих классах, со многими посторонними и деталями, которые не нужны для обзора.

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

— Фрэнк Шиарар
источник

1

Если вы датируете документ, то он описывает архитектуру на момент написания.

Принимая во внимание, что код представляет архитектуру в настоящий момент.

Две разные вещи - не одно и то же знание.

Пока вы заявляете, что документ представляет собой архитектуру на момент написания, вы не дублируете знания IMO, потому что это разные знания, если речь идет о системе в другой момент времени.

— Никто
источник

Код никогда не представляет архитектуру. Это просто проявление архитектуры. Код, который был изменен сегодня, все еще может представлять архитектуру вчерашнего дня. Кроме того, он может не представлять предполагаемую (или требуемую по договору) архитектуру, о чем вам стоит больше всего беспокоиться. Код не говорит вам, правильно это или нет, только то, что он работает. Чтобы узнать, правильно это или нет, вы должны взглянуть на предполагаемую архитектуру и требования, которые привели систему в действие с самого начала.

— luis.espinal