Дисциплина принципов

Чем больше я вожусь с тяжёлыми и сложными проектами, тем больше я убеждаюсь, что дисциплина принципов - самая важная из всех. Принципы, положенные в основу проектов, либо соблюдаются, либо нет. Если они не соблюдаются, то оппортунистические принципы становятся из опоры обузой. Проект без принципов превращается в local scoped magic, когда изменения тем сложнее, чем больше подсистем задевают. Чем более глобальны измненения, тем важнее соблюдение принципов. Вторая проблема, которая наступает в проекте без соблюдения принципов, это расширение blast radius без возможности его ограничить или понять зону поражения. Любая ошибка вызывает труднопредсказуемые последствия.

На более низком уровне (в разборе причин) можно увидеть паталогические связности, вызывающие каскадные изменения в труднопредсказуемом виде, но "паталогические связи" - это результат оценки связей через принципы огранизации этих связей. Сказать, что связь является "паталогческой" можно только если есть возможность описать правильную структуру связей, причём не исходя из "собственного мнения о том, как оно должно быть", а из принципов, положенных в проект для организации этих связей. В отсутствие дисциплины вокруг принципов (то есть выполнения принципов или минимального отклонения от них), само понятие паталогической связности исчезает, потому что "если оно работает, то и хорошо", а виноват в поломке оказывается тот, кто не учёл всех связей в проекте. А учесть все связи в проекте можно только в условиях предсказуемости этих связей, то есть тех самых принципов.

Из всех изменений, нарушение принципов наименее заметно. Оно работает, оно покрыто тестами, оно легко подстраивается под новые требования, разумеется, не всегда (всегда не бывает). И вот во моменты "не всегда" наступает самая большая катаклизма. Нужно изменение. Его нельзя внести легко, потому что нарушившая принципы компонента всё равно имеет свои принципы, то есть возникает конфликт между принципами организации двух компонент. По закону подлости нарушающая компонента имеет большую сложность и важность, и с лёгкостью побеждает менее важную и примитивную компоненту, выполненную в рамках принципов проекта, после чего образуется вторичный метастаз - компонента, которая каким-то образом стыкует два конфликтующих принципа. Если это делается через подстройку принципов проекта (с учётом его в существующем коде) - ок, это эволюция. Если это делается через неожиданное (но элегантное) решение, то возникает сложная паталогическая свзяность. Несколько таких отклонений, и несколько невинных компонент оказываются источником невообразимой боли и ненависти всех, кто к ней прикасается.

Решением этой проблемы может быть только дисциплина: если один принцип меняется на другой (во имя нужного изменения), то этот принцип должен быть sound (сочетаться с остальными), а все отклонения/нарушения должны быть купированы или переделаны.

Чем толще проект, тем сложнее становится эта операция; именно тут находится самое большое зло больших проектов - они настолько большие, что никто не может изменить принцип их работы за разумное время. С этого момента проект "костенеет" (живёт только старыми принципами), либо превращается в спагетти (теряет дисциплину).

Потенциальным решением является наличие принципа минимизации размера "доменов взаимодействия" с очень жёсткими контрактными интерфейсами (привет, микросервисы); но это тоже принцип, и его нужно поддерживать дисциплиной...

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