Архитектура ПО: что это значит и как выстроить свою
Все разработчики, с которыми мне приходилось сотрудничать, так или иначе упоминали термин «архитектура». Хотя это очень размытое понятие, им оперируют почти все. Я долго пытался разобраться сам: что имею в виду, когда говорю, что это часть архитектуры, а это — нет. Статьи на Wikipedia и в некоторых других источниках крайне занудные. Похоже, что понятие довольно старое и не имеет четкого определения внутри современных Agile стилей разработки. Но мы по-прежнему оперируем им. Поэтому постараюсь дать определение этому понятию в рамках Agile Development Process.
Что считать архитектурой
Начнем с того, на чем сходятся все источники:
- Архитектура — это фундаментальные договоренности и решения.
- Архитектура — это нечто важное.
- Архитектуру сложно менять.
- Архитектура должна быть использована повторно (в силу своей клевости, естественно).
Это, пожалуй, все. Помимо этого, есть много шума о том, как именно она должна создаваться и какие есть подходы по управлению ею. Во всех этих описаниях используются такие мудреные слова, что сложно представить подобные процедуры в рамках Agile процессов.
Важная мысль, которая, как мне кажется, является истоком понятия архитектура, — «Архитектурные решения сложно менять» или, другими словами, «Решения, которые сложно поменять, — архитектурные». И это действительно то, что имеет наибольшее значение.
То, насколько сложно поменять решение, определяет степень его архитектурности. Также важно, что любое решение легко поменять на следующий день после его принятия или легко поменять решение, которое мало на что влияет. Причем в данном случае «решение»- это как программное решение, так и просто договоренность (которая рано или поздно все равно закрепляется программным решением).
На уровне кода это можно выразить так: архитектурный код или софт — это тот, который используется повторно наибольшее количество раз. Причем это правда как для кода, написанного вами лично, так и для заимствованного.
Пример: степень архитектурности базы данных — это количество данных, которые в ней хранятся. То есть чем больше вы храните данных в этой конкретной базе, тем более архитектурна она для вас. С другой стороны, подключенная к проекту база данных, в которой пока или уже ничего не хранится, архитектурой не является. При этом важно сделать упор именно на то, насколько сложно потом эту базу сменить. Например, если вам понадобится поменять MySQL на PostgreSQL, то архитектурность MySQL будет зависеть от количества специфичных ее фич, которые вы использовали.
Очень важно отслеживать архитектурность тех или иных решений по мере развития проекта, а не только при его зарождении. В outsource-компаниях часто встречается подход, когда в новый проект приходит важный дядя (например, CTO компании) и создает архитектуру, а на следующий день уходит из проекта. Его решения действительно важны, но архитектура им не строится, а строится теми, кто эти решения использует.
Так, возвращаясь к примеру с базой данных, важно отмечать дополнительные завязки на MySQL по мере их появления. Если вы используете ORM поверх базы — появляются они, как правило, не сразу, а намного позже.
Что важно заложить в начале проекта
Конечно же, в начале любого проекта принимается много архитектурных решений: как хранить данные, какой выбрать язык программирования, какой framework? Но также важно понимать, что все еще можно поменять на первых стадиях работы над проектом. И только со временем эти решения становятся настоящей архитектурой — той, которую сложно поменять.
С этой позиции не все начальные решения покажутся настолько прям архитектурными. Например, выбор языка программирования — явно архитектурное решение, потому что его изменение почти равносильно переписыванию проекта с нуля. А выбор key-value базы данных — не очень фундаментальное решение, поскольку подобных баз данных много и можно заменить одну на другую гораздо легче и незаметнее. Сделать это до выхода проекта в production вообще не составляет особого труда.
Очень часто в новых проектах доминирует философия: «Нам нужно с самого начала сделать все правильно, потому что потом у нас не будет времени что-то менять». Это правда, потому что все время потрачено на то, чтобы сделать все правильно, а не на то, чтобы делать корректировки по ходу, которые и представляют собой суть Agile процесса.
Кроме того, команда или отдельные люди часто не хотят признавать ошибочность своих первоначальных решений или хотя бы непредсказуемость развития проекта. Agile, увы, так не работает... По моему опыту, вот список базовых вещей в порядке их важности, которые следует выбрать правильно изначально и потратить на это дополнительное время:
- Структура хранения данных
- Язык программирования
- Development Framework
Все остальное, как правило, можно поменять или выбрать по ходу с гораздо меньшей ответственностью. Если ваш проект проживет достаточно долго, то рано или поздно все остальное придется менять и адаптировать.
Своя или заимствованная архитектура
Зачастую заимствованные программные решения гораздо проще поменять, чем собственные разработки. Так происходит потому, что заимствованный софт совсем ничего не знает о ваших личных целях и задачах. Он решает общие для всего software-community проблемы, которые решены не один раз и похожим способом: поменять один хостинг на другой будет несравнимо проще, чем поменять структуру данных, вами же созданную.
Создание архитектуры из собственного кода в долгоиграющих проектах очень важно. Все начинается с простого повторного использования кода: кто-то написал класс или метод и кто-то им воспользовался. Архитектурность кода как раз определяется количеством его повторных использований. Первый хороший звоночек, что у вас это получается — если написанный вами метод используют другие члены вашей команды без принуждения. Это говорит о том, что им проще положиться на ваш код, как на архитектуру, чем создавать что-то с нуля.
Все мы знаем, как программисты любят создавать велосипеды. Причин этому две. Очевидная — неумение этих программистов адаптировать существующие решения под свою задачу. И неочевидная — низкое качество кода внутри проекта. Думаю, что каждый из нас был по обе стороны баррикады: не хотел использовать код, написанный другими, и писал код, который другие не хотят использовать. Архитектуру можно построить, только если научиться писать свой качественный код и применять старый код.
Так или иначе при очередном повторном использовании код нужно адаптировать. И здесь важную роль играют тесты. Именно они помогут убедиться, что после адаптации код так же хорошо выполняет старые задачи, как и новые.
Как же построить свою архитектуру
- Следить за явными и не очень явными повторениями кода и устранять их сразу.
- Искать решения похожих проблем, а не только в точности одинаковых.
- Писать тесты.
- Обобщать и адаптировать старые решения под новые задачи.
- Понимать необходимость создания собственной архитектуры для конкретного проекта как важной надстройки над заимствованной.
- Не бояться менять и расширять код других членов команды (особенно экс-сотрудников, кода которых все боятся как огня).
- Создавать что-либо с нуля, только если достаточно уверены, что нет абсолютно никаких наработок на эту тему внутри проекта.
- Понимать, что создание архитектуры — непрерывный процесс, а не просто разовая акция по принятию архитектурных решений.
- Отслеживать степень завязки проекта на конкретные решения и своевременно их корректировать по ходу его развития.
