> в любой команде есть какие-то законы, которые придуманы фиг пойми для чего

Вот это основная суть статьи. Это - самая главная проблема в разработке. И это касается не только правил, но и кода:

📝 "A six-month study conducted by IBM found that maintenance programmers “most often said that understanding the original programmer’s intent was the most difficult problem”" - Fjelstad and Hamlen

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

Классический пример - из-за неудачного названия микросервиса логика размазывается и дублируется. Из-за дубликатов и плохих названий становится непонятно, в каком именно микросервисе наращивать логику, куда "поселить" новый инкремент логики.

Но даже когда намерения автора понятны, должна быть возможность выполнить задачу в существующем коде, т.е. изменить код автора. Если код представлен лапшой, то придется изменять много кода, изменения будут лавинообразными. По этому поводу хорошо рассуждал Kent Beck: https://t.me/emacsway_log/188

Чтобы код не был лапшой, нужно изолировать изменения. Поэтому, второе самое важное правило Software Design - это принцип "Low Coupling & High Cohesion" ( http://wiki.c2.com/?CouplingAndCohesion ), сформированный еще в 1974 году. Главное правило рыбака - не дать запутаться леске. Главное правило программиста - предотвратить Уроборос.

И, наконец, третье важное правило - чтобы что-то изменить, нужно понять, как оно работает сейчас. А для этого нужно иметь возможность рассмотреть фрагмент программы изолированно, чтобы сложность рассматриваемого фрагмента не превысила ограниченные возможности краткосрочной памяти человека.
https://ru.m.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE_%D1%81%D0%B5%D0%BC%D1%8C_%D0%BF%D0%BB%D1%8E%D1%81-%D0%BC%D0%B8%D0%BD%D1%83%D1%81_%D0%B4%D0%B2%D0%B0

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

> От навязанных необоснованных ограничений мы получаем выгорание.

Тут он говорит то же самое. Объектом критики выступают не сами правила, а отсутствие понимания причин этих правил. Именно поэтому, одной из самых ключевых практик Agile-разработки является Collaborative Development (т.е. методики распространения знаний). Понимание - единственная причина, позволяющая гарантировать соблюдение правил.

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

#SoftwareDesign