56 законов разработки на одном сайте

56 законов разработки на одном сайте

Наткнулись на отличный ресурс: Laws of Software Engineering. 56 принципов и паттернов, которые реально влияют на то, как мы пишем код, строим архитектуру и работаем в командах.

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

Закон Хофштадтера говорит, что всё всегда занимает больше времени, чем ожидаешь, даже с учётом самого закона Хофштадтера. Звучит как шутка, но любой, кто хоть раз давал оценки на спринт, знает: это не шутка.

Закон Брукса напоминает, что добавление людей в горящий проект только замедляет его. Фред Брукс сформулировал это ещё в 1975 году в книге «Мифический человеко-месяц», и с тех пор в индустрии мало что изменилось. Новый человек тратит время на онбординг, существующие разработчики тратят время на его введение в курс дела, коммуникационных связей в команде становится больше, а скорость падает. Именно поэтому «давайте наймём ещё одного разработчика» почти никогда не спасает дедлайн. Книга вышла полвека назад, но каждый, кто хоть раз видел горящий проект, подтвердит: закон работает до сих пор.

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

Закон Галла говорит, что любая сложная система, которая работает, выросла из простой системы, которая тоже работала. Никто не проектирует сложность с нуля и не получает рабочий результат. Сначала простая система, которая решает реальную задачу, потом постепенное усложнение. Отсюда и YAGNI, и итеративная разработка.

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

Таких законов на сайте 56, они разбиты по категориям (архитектура, команды, планирование, качество) и уровням от джуна до сеньора.

p.s. Сколько из этих законов вы знали?

Telegram | YouTube | Сообщество