Как законы и принципы в разработке спасают команды от хауса
Напишу про самые известные. Им необязательно нужно прям 100% следовать, но взять во внимание, порой стоит - очень помогает.
1. Закон Галла. Эффективная сложная система всегда развивается из эффективной простой системы. Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде.
2. Принцип Парето. Около 80% эффективных результатов достигается за счёт 20% ключевых усилий.
3. Закон Паркинсона. Работа расширяется, чтобы заполнить время или бюджет, отведённые на её выполнение. Это значит, если разработчик, к примеру, выделил на задачу неделю, столько он и будет её делать скорее всего.
4. Закон Гудхарта. Это про метрики. Когда мера становится целью, она перестаёт быть хорошей мерой. Потому что становится объектом манипулирования как прямого (фальсификация чисел), так и косвенного (работа исключительно для улучшения этой меры).
5. Закон Брукса. Добавление рабочей силы на поздних стадиях разработки продукта замедлит его релиз.
6. Закон Линуса. При достаточном количестве наблюдателей ошибки выплывают на поверхность.
7. Принцип «Чем хуже — тем лучше». ПО, которое имеет ограничения, но простое в использовании, более востребовано пользователем и рынком, чем не имеющее ограничений, но сложное для понимания.
8. Закон кибернетической энтомологии. Всегда есть ещё один баг.
9. Закон Кернигана. Отладка кода вдвое сложнее, чем его написание.
10. Правило 90-90. Создание 90% кода ПО занимает 90% заложенного времени разработки. Оставшиеся 10% — ещё 90% времени.
11. Закон Хофстадера. На выполнение задачи всегда уходит больше времени, чем ожидаешь, даже если принять во внимание закон Хофстадера.
12. Закон Хатбера. Улучшение одной части системы ведёт к разрушению других частей, или прячет иные типы разрушения, что в целом приводит к деградации системы по сравнению с текущим её состоянием.
· 19.05.2025
Самое интересное, большинство законов и принципов можно перенести в другую проектную область.. И если брать их во внимание, можно довольно много событий спрогнозировать и смоделировать, чтобы развитие проекта шло более плавно, а не радикально-циклично. Спасибо за полезный пост)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 19.05.2025
Спасибо) надеюсь было полезно.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 19.05.2025
Согласен, в жизни тоже применимо)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён