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

вы скорее поймете глубинные принципы работы UNIX. Концептуально структуры данных имеют гораздо меньший размер и существенно более просты по сравнению с кодом.

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

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

Данные находятся в центре большинства задач. Задачи, относящиеся к предметной области, проникают в код через данные. Большинство ключевых алгоритмов хорошо изучены и проанализированы, а вот структура данных и связи между ними изменяются часто. Проблемы уже работающих систем (такие как обновление) также существенно усложняются, если затрагивают данные. Изменение кода или поведения — не такая уж серьезная проблема: нужно просто выпустить новую версию системы; но изменение структур данных может потребовать огромных усилий по преобразованию старой версии данных в новую.

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

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

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

Простое должно быть простым

Чед Лавинь

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

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

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

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

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

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

Архитектор — прежде всего разработчик

Майк Браун

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

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

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