Прочитал очередную часть “Чистой архитектуры”. В главах рассказывалось про принятие решений и развитие проекта. Ниже немного мыслей на этот счёт.
Поинт 1. Мы не знаем, как будет развиваться наш проект.
Нам очень хотелось бы все понимать и создать идеальное решение, но в реальности так не бывает почти никогда. Вспомните сколько раз все поменялось в какой нибудь крупной фиче на проекте. Даже методологии разработки исходят из того, что мы точно не знаем что нам нужно и плохо умеем в долгосрочное планирование. Это про продукт. С кодом же ещё сложнее. Каждое продуктовое направление развития может быть по разному реализовано технически. Даже если вы думаете что путь развития продукта понятен и очевиден и на 100% уверены в том, какая будет техническая реализация, все может поменяться очень быстро. И лучше быть к этому готовыми.
Из этого следует вывод, который плохо укладывается в голове и противоречит тому, каким мы видим хорошего разработчика.
Поинт 2. Нужно максимизировать количество открытых вопросов в проекте.
В книге прямо говорится, что хороший архитектор оставляет как можно большее количество вопросом без ответа.
Почему? Мы плохо умеем в прогнозирование. И поэтому лучше принимать решения как можно позже. Тогда у нас будет больше информации и уверенности в действиях. И делать так очень непросто. Каждый разработчик ценен тем, что решает задачи бизнеса с помощью технологий. Нам это нравится и в нас это ценят. Поэтому сложно оставить вопрос открытым. Сложно пройти мимо проблемы и сказать «Мы сейчас тут ничего не будем делать». Особенно сложно если мы видим возможное решение и оно нам нравится. Но если задача не нужна бизнесу прямо сейчас то скорее всего мы сделаем ряд предположений и реализуем так, как нам кажется будет нужно бизнесу.
Есть другая формулировка этого правила. Она более конструктивная и воспринимается лучше.
Поинт 3. Нужно как можно дольше иметь как можно больше вариантов.
Реализуя код исходя из предположений мы сокращаем количество доступных нам опций развития проекта. Мы одну реализовали непосредственно и ещё часть заблокировали тк реализованное решение противоречит им или несовместимо с ними.
В этом по мнению Мартина заключается искусство разработки проектов с хорошей архитектурой. Реализовывать только то, что действительно нужно и иметь как можно больше вариантов. Чтобы когда мы поняли точно, что хотим сделать у нас был достаточный набор возможностей и мы не осознали, что хороший вариант в текущей ситуации невозможен потому что мы приняли неверное решение в прошлом и отграничили себя.
Я понаблюдал некоторое время за принимаемыми в проекте решениями и за обсуждениями того, какую реализацию выбрать. Те решения которые считаем хорошими не всегда очень технологичные, не всегда полностью и идеально закрывают задачу. Но они всегда простые и оставляют достаточно пространства для манёвров в будущем.
За рамками статьи осталась тема про “не продолбать, то что действительно понадобится”. Например увеличить количество серверов, устранить уязвимость в системе и тп. Тут как мне кажется нужно задавать вопрос “А не умрем ли мы, если это не сделаем”.