Неизбежность эволюции программных систем
Многие сходятся в том, что, начиная новый проект, нужно начать с чего-то простого, чтобы как можно быстрей сделать MVP и получить первую обратную связь. Вполне разумный и рациональный подход. Действительно, зачем собирать космический корабль, который, возможно, никогда не выйдет за пределы ангара или на содержание которого нет ни денег, ни людей. Тем не менее в душе каждого творца всегда искрится надежда создать нечто уникальное и неповторимое. Почему бы не поддаться этому порыву в новом/текущем проекте?! Как понять, что пришло время для особенных решений?!
На самом деле подобная постановка вопроса некорректна. Практически любое решение никогда не бывает финальным, тем более сразу. Об этом пишут многие заслуженные авторы, но самой яркой цитатой, пожалуй, является закон Голла.
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Позволю себе внести важные уточнения.
- Простота системы означает не примитивизм, а наличие ограниченного числа взаимодействующих между собой элементов с понятными и прослеживаемыми связями между ними.
- Сложность системы означает не трудность организации самой системы, а её зрелость, точность модели предметной области.
Таким образом, если принять неизбежность эволюционного развития систем, тогда гораздо более важным аспектом является возможность самой эволюции. Для этого нужно обеспечить, как минимум, два условия. Во-первых, поскольку на начальных стадиях слишком много неопределенности, нужно как можно дольше сохранять свободу выбора направления развития. Во-вторых, принимаемые решения должны уточнять вектор движения для развития в желаемом направлении. Именно в этом контексте речь идет о гибкости архитектуры.
Гибкость архитектуры — понятие ортогональное к простоте и сложности, означающее степень готовности системы к изменениям. Простая не значит гибкая, обратное также справедливо. Гибкость становится возможной, в том числе, если система не зависит от специфических возможностей составляющих её элементов или особенностей взаимодействия между ними. Например, гибкость снижается, если появляется зависимость от уникальных особенностей определенной базы данных или зависимость этой базы данных от определённого окружения. Между тем, слишком гибкое решение — бесформенное, рыхлое, оно не может задавать структуру, следовательно, вектор развития, обрекая весь проект на провал.
Подобные умозаключения не являются каким-то открытием, об этом пишут и говорят многие. Я лишь хочу подчеркнуть, что для архитектора важно не только принять обоснованное решение, но и определить пути его дальнейшего развития. Нужно мыслить на несколько ходов вперед, как можно дольше сохраняя простоту и гибкость решения. Пожалуй, это лучший ответ на исходный вопрос о своевременности и возможности тех или иных решений. Каждый следующий шаг должен приближать нас к цели, формировать базу для следующего шага и уточнять направление развития. Если это так, то действуйте!
Именно под таким углом нужно смотреть на обоснование очередного решения. По этой причине нужно сразу отбрасывать нижеследующие "обоснования", которые, несмотря на свою комичность, к сожалению, всё-таки встречаются.
- Выбор технологии, принимая во внимание только её популярность. ("Так принято в лучших домах!", "Kafka справится с любой задачей" и т.п.)
- Немедленные действия, обоснованные амбициями или ощущениями. ("Некогда думать — надо действовать!", "Мир сам себя не захватит!", "Это слишком дорого, но я не скажу, насколько" и т.п.)
- Неоправданное и/или преждевременное усложнение. ("У меня нет задач, нужно придумать что-то интересненькое", "У меня скучные задачи, нужно добавить драйва", "Я предусмотрел обработчик на случай вторжения инопланетян!" и т.п.)
- Неоправданное расширение технологического стека. ("CV-Driving Development", "Решил попробовать", "Мне так удобней" и т.п.)
Принимая неизбежность эволюционного развития систем, важность гибкости архитектуры на ранних стадиях, а также необходимость постоянной корректировки направления развития (стратегии), остаётся вопрос, почему кто-то начинает не с простых вещей. Почему кто-то сразу начинает с гексагональных архитектур или микросервисов?
Согласен, что иногда это является преждевременным усложнением. Однако, если архитектор или разработчик достаточно опытный, он может позволить себе "срезать углы", действуя на опережение. В данном случае он должен осознавать и указывать на все риски подобных действий, в том числе понимать, кто будет поддерживать и сопровождать такой продукт. Тут можно вернуться к метафоре с "космическим кораблём": нужен ли он на старте, есть ли у вас подходящая команда, инфраструктура, ресурсы?
Я постарался описать тактику принятия решений, которой стараюсь пользоваться в работе. К сожалению, иногда эмоции берут верх, и приходится себя останавливать. Было бы интересно узнать, как вы справляетесь с соблазнами несвоевременного применения понравившегося решения.
P.s. Если вам интересна данная тематика, присоединяйтесь к моему каналу "Архитектоника в ИТ" в Telegram или VC. Буду рад поделиться опытом. ;-)