Найти тему

Архитектура

Оглавление

Какое красивое и с(т)ильное слово. И это действительно так. Но давайте немного порассуждаем.

При общении с ребятами на 1 to 1 или просто в общении с разработчиками, я часто слышал, что особенно нравится решать «интересные» архитектурные задачи.

Откуда такой интерес именно к архитектурным задачам? На мой взгляд, все задачи интересные )

Скорее всего интерес приходит от причастности к созданию архитектуры приложения, это ведь так круто, не так ли? А еще, обычно архитектуру делают сеньоры, стало быть чем раньше начнешь делать такие задачи, тем быстрее станешь сеньором. Интересный ход мыслей, но тогда уж лучше переехать в Мексику — вопрос решится сразу.

Еще, начинающие разработчики смотрят вокруг и видят кучу разных архитектурных аббревиатур и начинают пытаться понять, что они означают и как работают. Это похвально, конечно, и нужно. Но и перебарщивать не стоит. Дело это итерационное, нужно соблюдать баланс. А баланс будет все равно перетягивать в практику. Так что как ни крути, а поработать придется. Эхх... к сожалению, видосы на ютьюбе не сделают из тебя архитектора за 30 минут.

А еще, может создаться впечатление, что если мы развернем проект на Vue или на Laravel, то тут же получим готовую классную архитектуру и все будет ОКей. Но тоже нет. И то и другое — отличные штуки, но не про архитектуру. Архитектура все равно остается на вас.

На любом самом прекрасном фреймворке можно накодить много чего, что потом спишется в утиль (читай легаси). А все потому, что либо сам фреймворк ошибочно считается архитектурой, или на архитектуру забили вовсе.

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

Определение

Архитектура — это набор компонентов, с четко указанной семантикой, необходимый для реализации поставленной задачи.

Да, вот такое простое определение, для такой сложной штуки. Да и вообще, с чего вы взяли, что архитектура должна быть сложной? На мой взгляд, архитектуру нужно делать простой. Простая архитектура — это признак высокого мастерства. Сложная — как бы говорит нам: «попробуйте еще раз».

Но задачи, конечно же, разные бывают. Нужно смотреть на соотношение сложность задачи / сложность архитектуры.

Ладно, с определением разобрались. Но хочется ввести еще одну штуку — ограничение.

Ограничение

Расширение архитектуры должно производиться только в случае действительной необходимости.

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

Кратко рассмотрели основные тезисы, теперь к маркерам.

Маркеры хорошей архитектуры

  • Компоненты хорошо просматриваются при Helicopter View
  • Для решения новой задачи не приходится корректировать компонентный состав архитектуры
  • Онбординг нового специалиста происходит в течение короткого времени — 3-5 дней
  • Не нарушаются потоки приложения
  • Хорошо понятны достоинства и недостатки текущей архитектуры
  • Хорошо понятны дальнейшие шаги при эволюции архитектуры
  • Клиентский код лаконичный и декларативный
  • Работа с кодом не доставляет неудобств
  • Время на обратное погружение в код минимально — 10-15 минут

И самый главный маркер я вынесу отдельно:

Бо'льшая часть времени уходит на разработку функциональности, а не на инфраструктуру или фикс багов.

Основная задача архитектуры

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

Основная задача архитектуры — в условиях переменчивости бизнес-требований обеспечить быстрое и надежное изменение системы.

Так что смотрите на результаты. Если функциональность добавляется с завидным успехом, значит архитектура хороша. Если нет — применяйте маркеры к своему проекту и смотрите, где что расходится.

На этом пока остановлюсь. Удачной работы и крутых результатов!

Не забывайте делать хорошо и «чуточку» лучше! 🔥

Подписывайся на мой канал в TG: https://t.me/cantfailcode