Совершенный код

Когда вместе собираются критики, они говорят о Теме, Композиции и Идее. Когда вместе собираются художники, они го* ворят о том, где купить дешевый скипидар. Шт Пикассо

В архитектуре должны быть обоснованы важнейшие принятые решения. С подозрением относитесь к обоснованиям из разряда «мы всегда так делали». Здесь уместно вспомнить одну поучительную историю. Бет хотела приготовить тушеное мясо по прославленному рецепту, передававшемуся из поколения в поколение в семье ее мужа Абдула. Абдул сказал, что его мать солила кусок мяса, перчила, обрезала его края, укладывала в горшок, закрывала и ставила в духовку. На вопрос Бет «Зачем обрезать оба края?» Абдул ответил: «Не знаю, я всегда так делал. Спрошу у мамы». Он позвонил ей и услышал: «Не знаю, просто я так всегда делала. Спрошу у твоей бабушки». А бабушка заявила: «Понятия не имею, почему вы так делаете. Я делала так потому, что мой горшок был маловат».

Если, например, вы разрабатываете программу для Microsoft Windows, зачем
ограничивать себя средой Windows? Изолируйте вызовы Windows в специализи-
рованной интерфейсной подсистеме, и если вам позднее захочется перенести
программу на платформу Mac OS или Linux, то придется изменить только эту
подсистему.

Вы может скрыть детали реализации доступа к
БД, чтобы большая часть программы не нуждалась в знании «грязных» подроб-
ностей операций над низкоуровневыми структурами и могла работать с данными
в терминах бизнес#проблемы. Подсистемы, скрывающие детали реализации, обе-
спечивают важный уровень абстракции, снижающий сложность программы.

Иначе говоря,
программа не должна содержать циклических отношений, при которых класс A
использует класс B, класс B использует класс C, а класс C — класс A.

Стрелки между подсистемами можно рассматривать как шланги с водой. Если вам
захочется «выдернуть» одну из подсистем, к ней наверняка будут подключены не-
сколько шлангов. Чем больше шлангов вам нужно будет отсоединить и подключить
заново, тем сильнее вы промокнете. Архитектура системы должна быть такой,
чтобы замена подсистем требовала как можно меньше возни со шлангами.

Стремление к краткости методов программы помогает снизить нагрузку на ин-
теллект. Этому же способствует написание программы в терминах проблемной
области, а не низкоуровневых деталей реализации, а также работа на самом вы-
соком уровне абстракции.

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

ак только вы поймете, что все остальные технические цели разработки ПО вто-
ричны по отношению к управлению сложностью, многие принципы проектиро-
вания окажутся простыми.

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