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

И конечно, многие фундаментальные проблемы архитектуры программного обеспечения в действительности связаны с данными. Собирает ли система правильные данные в правильное время? Кто должен иметь возможность просматривать или изменять эти данные? Если данные уже существуют, насколько они качественны и как быстро растет их объем? Если данных пока нет, то какова их структура, откуда они поступят и насколько надежен их источник? А когда данные окажутся в системе, останется еще один вопрос: есть ли способ просмотра и/или редактирования конкретных данных или его необходимо добавить в систему?

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

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

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

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

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

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

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

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

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

Архитектор — прежде всего разработчик Майк Браун

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