"Лучший ход Кажется, я долго искал критерий хорошего архитектурного решения. Сейчас думаю про четыре штуки, которые одновременно делает ""лучший ход"": __1. Даёт локальную пользу уже сейчас. 2. Уменьшает глобальный разрыв в системе 3. Делает следующий хороший ход дешевле. 4. Увеличивает вероятность того, что этот путь повторят другие.__ Последний пункт кажется самым важным. Если решение приходится каждый раз продавливать заново, ландшафт не изменился. Настоящий рефакторинг: изменение формы поверхности, по которой движется вся система, без переписывания кода. После хорошего рефакторинга правильное решение начинает требовать меньше усилий, чем неправильное. Возможно, именно это и является настоящей единицей эволюции сложных систем. Если так смотреть, эволюция сложных систем идёт не через новые объекты, функции или процессы. Она идёт через сдвиги в стоимости следующего перехода. Хороший пример из нашей работы — текстовый daily в Slack по шаблону «доставлено / планирую / блокеры». Проверяется по всем четырём пунктам: __Локальная польза сейчас __— утром за 2 минуты команда видит, кто чем занят, без созвона. __Закрывает разрыв __— не нужно дёргать людей в личку «ну что там у тебя», блокеры всплывают сами. __Удешевляет следующий шаг __— если у кого-то затык, помочь можно сразу, а не когда уже сгорело. __Повторяют другие__ — новый человек в команде заходит в канал, смотрит вверх, копирует формат. Никто не объясняет заново. Форма поверхности изменена: написать по шаблону дешевле, чем не написать. Поэтому шаблон живёт сам, без напоминаний. А теперь посмотрите на свою команду. Поищите такие примеры — где хороший ход стал дешевле плохого сам собой, без напоминаний и продавливания. `Делитесь в комментариях. Давайте обмениваться опытом 👇`"