Навёяло беседой про "чистый код" в соседнем чате.

Обычно какая-нибудь известная компания выпускает статью, а возможно даже книгу с описанием применяемых методик. Тут же находятся энтузиасты которые призывают немедленно эту самую методику внедрить, применить и поставить во главу угла. И тут начинается интересное.

Дело в том, что те самые "лучшие практики" были лучшими тогда и там где их придумали. Самая близкая аналогия это лечение болезней. Обаятельно в какой-то момент появится "знахарь" заявляющий, что вот у тех-то больших ребят в хирургическом отделении все отлично получается, а они все проблемы решают зелёнкой, спиртом и скальпелем, поэтому давайте срочно в нашей пульмонологии тоже так делать, а что воспаления лёгких зелёнкой лечатся плохо, так это вы ее льёте мало!

Последнее десятилетие из-за того что большую часть денег IT компании получали от инвесторов, используемые технологии начали приобретать очертания рынка моды - что хорошо продаётся инвесторам, то и пишем в технические требования.

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

Безусловно все эти методики являются отлично продуманными с точки зрения их продажи бизнесу, отвечают на все возможные вопросы и аккуратно оговаривают риски. Проблема заключается в том, что формально являясь оптимальными, фактически большая часть из них не ставит своей целью построение грамотной работы команды или компании, потому что жизненный цикл методологии фактически заканчивается на моменте получения средств инвесторов.

В целом, внезапно, строить систему с использованием "чистого кода", "lean / agile" и прочих "лучших практик" часто не только вредно, но и бесполезно. Если конечно целью не стоит получить бюджет и гордо обновив резюме уйти в туман.

В России традиционно все новомодные технологии и практики обычно приходят с задержкой от двух до пяти лет, поэтому год-два назад мы видели пик хайпа микросервисной архитектуры, методологий гибкой разработки и прочих "современных" подходов.

Сейчас в считающих деньги компаниях, где эти подходы приняли в работу, происходит отрезвление, осознание и плавный откат к методам построения команд и прода оптимальным с точки зрения получения результата, а не красоты презентаций.

Мысль всего вышеизложенного простая - копировать методики и "лучшие практики" необходимо сначала осознав какую проблему они решают и если они вдруг решают именно вашу проблему, то плавно адаптировать эти практики через обратную связь от команд. Но это конечно скучно, нудно и никак не даёт возможности хайпануть на совещании о том что "мы за месяц перешли на super giga mega agile" и теперь-то наконец заживем!

Поэтому когда вам на собеседовании рассказывают о новых методологиях и прорывных технологиях - будьте внимательны!

Что еще почитать?

Про SRE и отказоустойчивость
- Почему падает прод?
- Что такое SRE?
- Оптимизация и стоимость в сегодняшнем IT
- Что такое Chaos Engineering?

Про инженерную культуру
- Зачем нужна инженерная культура
- Как на собесе понять, что в эту компанию тебе не надо
- Индикаторы упадка компании
- Можно ли в одиночку поменять культуру в компании

Как делать и как не делать
- Мониторинг и алертинг
- Антипаттерны в DevOps и SRE
- Культура взаимодействия между DevOps и SRE

Базы данных
- Базовая настройка MySQL
- Настройка транзакционного лога InnoDB в #MySQL


#обсуждения
https://t.me/downtime_bar