Pull to refresh

Comments 5

вступает в силу второй закон архитектуры: любое решение является компромиссом, у которого есть сильные и слабые стороны

А какой первый? А лучше огласите весь список, пожалуйста

Первый: любое решение в архитектуре - это компромисс.

С плюсами всегда в наборе получаешь минусы. Нужно понять, какие архитектурно-значимые функциональные требования критичны и какие нефункциональные требования порождают. Далее - ранжирование по критичности (требования могут быть диаметрально противоположными: хочу чтобы система выдерживала 1млн запросов/сек - high throughput и задержка ответа составляла не более 10мс - low latency) и подбор паттерна, который лучше подходит для выполнения критичных требований.

Фиксация минусов и проработка, чем их нивелировать или какие риски нужно принять (иногда достаточно просто о них знать, так как они могут проявляться в каком-то изменившемся контексте или новых требованиях).

@komgbu прав, а вот я в статье слегка напутал

В книжке выводится всего два закона архитектуры.

Первый закон:

Everything in software architecture is a trade-off.

Любое решение является компромиссом (о чём @komgbu чётко расписал).

Второй закон:

Why is more important than how.

Вопрос "почему" является важнее вопроса "как". Для меня это стало тоже очень ценным подспорьем в спорах с коллегами, которые слишком рано уходят в детали имплементации, не рассматривая картину целиком.

Ещё бывают ситуации, что архитектуру детально прописываешь, согласовываешь, создаёшь RFC, рисуешь диаграммы разного уровня детализации, составляешь секцию FAQ, а потом приходит человек и начинает спрашивать вопросы которые в явном виде уже описаны в документе. Просто ему/ей лень читать.?

Бывают такие люди, сам сталкивался. В таком случае помогает задать вопрос себе (да и ему/ей), настолько ли это уникальный человек в компании, что вам необходимо тратить на него время дважды. Потому что первый раз вы уже потратили время, детально всё описывая.

Sign up to leave a comment.