Радио «Виктор»: Почему компании тупят? Чем больше компания или даже конкретная команда, тем больше возникает регламентов и «глупых» правил. А в инженерной части все больше «квадратно-гнездового» и меньше ситуативно-эффективного. Инженеру непонятно, почему ему запрещают использовать тригеры в СУБД, если это решает его задачу. Почему линтер блокирует пайплайн с устаревшей библиотекой, хотя новая версия ничем не лучше. Почему требуют использовать Kafka только как Pub/Sub, и не использовать как распределенный лог или буффер, хотя Kafka «вообще-то для этого и создавалась». Такие вопросы я слышу почти каждый день, и они всегда заставляют меня задуматься: действительно ли предлагаемое решение более эффективно? Не всегда. Но бывает, что это действительно так. А прав ли инженер, утверждая, что эффективность в конкретном кейсе оправдывает исключение? В большинстве случаев — нет. Пример из управленческой плоскости: человек с зарплатой X увольняется из-за денег, а на его место после долгих поисков берут человека с зарплатой (X+20%) и меньшей квалификацией. Причины могут быть разными, но обычно они в плоскости того, что правила не позволяют повысить зарплату в этот период, для этого сотрудника, в этой стране (если компания международная) и так далее. Такие ситуации часто возникают, и на первый взгляд они кажутся нелогичными. Однако эти «неэффективности» тоже имеют своё объяснение. В обеих ситуациях, мы действуем не эффективно. Но почему? А все из-за того, что почти невозможно управлять крупной командой, регулировать крупную систему ситуационно. От случая к случаю. Вместо этого, есть два пути: дробить систему на более мелкие или придумывать общие правила, которые работают хорошо в большинстве случаев, но часто оказываются неэффективными в исключительных ситуациях. Каждое исключение из правил — это всегда риск. А риски на бесконечном горизонте «стреляют» всегда. Например, все микросервисы компании выкатываются в кубер единым пайплайном с общими правилами масштабирования и распределения по неймспейсам и зонам доступности. Мы делаем исключение для одного сервиса — полностью кастомный пайплайн, выкатывающий его в три разных неймспейса по одному на каждую зону доступности. Сначала все будет хорошо. Но через год или два мы захотим, чтобы доступ к секретам определялся неймспейсом. Вспомним ли мы, в этот момент, об исключении? Протестируем ли для него? Верно ли напишем логику исключения в новом коде? Ну, думаю, вы поняли, чем такое кончается... Но без исключений нельзя Хотим мы того или нет, но совсем без исключений тоже не получается. Иногда неэффективность становится настолько чудовищной, что важно сделать иначе, не смотря на риски. А еще есть легаси системы, есть внедренные «сбоку», есть переданные из других команд. И каждое из таких исключений висит, как Дамоклов меч. Или, если хотите, как Чеховское ружье. Вот и получается, что есть три стула: 1. Дробить систему и изобретать велосипед в каждой части — это приведёт к потерям времени и ресурсов. 2. Загонять всех в рамки и заставлять всех работать по одному сценарию — это создаст внутренние конфликты и снизит гибкость. 3. Делать исключения и страдать от их последствий. Вас ждет неочевидное поведение и аварии. Любая крупная компания выбирает сразу все три. Но разные компании, в разных пропорциях.