97 этюдов для архитекторов программных систем

Простое должно быть простым Чед Лавинь

Архитекторы программного обеспечения решают множество очень сложных задач, но наряду с ними встречаются и относительно простые. А вот чего мы стремимся избежать, так это решения простых задач сложными методами. Каким бы очевидным ни казался этот совет, следовать ему порой нелегко. Проектировщики программного обеспечения — умные, очень умные люди. Однако весьма легко попасть в ловушку «простая задача — сложное решение», потому что все мы любим демонстрировать свои знания. Если вы почувствовали, что проектируете решение настолько умное, что оно со временем, того и гляди, проявит искру самосознания, остановитесь и подумайте. Соответствует ли такое решение поставленной задаче? При отрицательном ответе рассмотрите заново варианты дизайна системы. Простое должно быть простым. У вас будет масса возможностей продемонстрировать свой талант, когда вы столкнетесь со сложными задачами, а это непременно случится.

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

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

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

Часто возникает сильное желание оправдать решения предполагаемой выгодой или прогнозируемыми требованиями. Запомните: когда вы пытаетесь угадать будущие требования, в 50 % случаев вы ошибаетесь, а в 49 % — очень-очень сильно ошибаетесь. Решайте проблемы по мере их поступления. Сдайте приложение вовремя и дождитесь обратной связи, чтобы сформулировать реальные требования. Созданная вами простая архитектура намного упростит реализацию новых требований в случае их поступления. А если вы все же угадаете и спрогнозированные вами требования станут реальными к следующей версии, то у вас уже будет в голове готовое решение. Отличие в том, что теперь вы сможете выделить для него должное время, потому что оно действительно необходимо. И вы с вашей командой опомниться не успеете, как завоюете репутацию профессионалов, способных хорошо оценить задачу и справиться со своей работой в срок.

Биография автора приведена ранее.