IT-законы и эмпирические принципы
Зачем эта полка
В IT часто цитируют «законы» — короткие эмпирические принципы, шутки и наблюдения, которые помогают быстро объяснить поведение людей, команд и систем. Это не физические законы: они не доказаны строго, но десятилетиями проверяются практикой и становятся общим языком на форумах, в ревью и на планёрках.
Статья — карта: формулировка, смысл в двух абзацах, куда идти за техникой. Рядом по духу — Рунетские IT-формулы (мемы и формулы рунета) и принципы проектирования (SOLID, DRY, закон Конвея).
В разделе 4.04 «Библиотека» речь о библиотеках кода (library в программировании). Здесь — справочная полка принципов, как у подборки литературы, только без обязательства читать книгу целиком.
Сводная таблица
| Принцип | Краткая формулировка | Где углубиться |
|---|---|---|
| Закон Каннингема | Лучший способ получить правильный ответ в сети — опубликовать заведомо неверный | Поиск, интернет-культура |
| Закон Линуса | При достаточном числе наблюдателей все ошибки становятся «мелкими» | Open Source, тестирование |
| Закон Брукса | Добавление людей в отстающий проект задерживает его ещё сильнее | Планирование конструирования |
| Закон Вирта | ПО замедляется быстрее, чем железо ускоряется | Оптимизация размера и производительности |
| Закон Мёрфи | Всё, что может пойти не так, рано или поздно пойдёт не так | Отказоустойчивость, DevOps |
| Закон Амдала | Ускорение ограничено долей последовательного кода | Законы производительности параллельных систем |
| Принцип Питера | Сотрудник повышается до уровня некомпетентности | Методологии и ЖЦ ПО |
| Закон Паркинсона | Работа заполняет всё отведённое на неё время | Планирование, Agile |
Закон Каннингема
Формулировка (шуточная, в честь Уорда Каннингема): «Лучший способ найти правильный ответ в интернете — не задать вопрос, а разместить заведомо неправильный».
На форумах и в issue-трекерах люди охотнее исправляют ошибку, чем отвечают на «голый» вопрос без контекста. Отсюда мем про второй аккаунт с заведомо неверным ответом — он иллюстрирует механизм, но намеренно вводить в заблуждение сообщество неэтично: лучше нормальный вопрос с MRE и текстом ошибки.
Разбор в контексте поиска и этикета — Эффективный поиск в интернете. Уорд Каннингем также известен как автор вики и участник XP — Smalltalk / философия.
Закон Линуса
Формулировка (Eric S. Raymond, эссе The Cathedral and the Bazaar, 1999): «Given enough eyeballs, all bugs are shallow» — при достаточном количестве наблюдателей все ошибки всплывают на поверхность.*
Идея open source: публичный код, issue и pull request привлекают много ревьюеров; редкие баги чаще находят до релиза, чем в закрытом репозитории с двумя разработчиками. Ограничения: критичный код всё равно нуждается в тестах, CI и ответственных мейнтейнерах; «много глаз» не заменяет безопасный дизайн.
Культурный контекст — Open Source, GitHub, DevOps и веб-стек; метафора «собор и базар» — Великие люди IT / Реймонд. Практика — тестирование, культура кода.
Закон Брукса
Формулировка (Фредерик Брукс, The Mythical Man-Month, 1975): «Adding manpower to a late software project makes it later» — добавление людей в отстающий программный проект только задерживает его ещё больше.*
Новые участники требуют онбординга, перераспределения задач и роста коммуникационных связей (см. также закон Конвея). На практике при срыве сроков чаще помогают срез scope, упрощение архитектуры и устранение блокеров, а не «добавить пять разработчиков к дедлайну».
Разбор в планировании — Стратегии планирования конструирования. Книга — в подборке литературы.
Закон Вирта
Формулировка (Никлаус Вирт, 1995): «Software is getting slower more rapidly than hardware is getting faster» — программное обеспечение замедляется быстрее, чем аппаратное обеспечение ускоряется.
Новые CPU и SSD дают кратный прирост, но приложения раздуваются — фреймворки, аналитика, фоновые сервисы, тяжёлые UI. Пользователь не всегда чувствует ускорение «железа», потому что софт съедает запас. Ответ инженера — профилирование, отказ от лишних зависимостей, метрики, а не слепая вера в новый процессор.
Системный разбор роста веса ПО — Оптимизация размера и производительности. Wirth как автор Pascal/Modula — модульность.
Закон Мёрфи
Формулировка (популярная, не IT-специфичная): «Anything that can go wrong will go wrong» — если что-нибудь может пойти не так, оно пойдёт не так.*
В инженерии это аргумент за предположение отказа: диски падают, сети рвутся, деплой ломает прод, человек удаляет не ту таблицу. Отсюда резервные копии, идемпотентность, health check, canary-релизы, runbook'и и культура постмортемов без поиска виноватого.
См. ошибки и отказоустойчивость, DevOps и CI/CD, резервное копирование.
Закон Амдала
Суть: ускорение от параллелизации ограничено долей кода, которую нельзя распараллелить. Даже на бесконечном числе ядер потолок ускорения — обратная величина этой доли.
Формулы, примеры и интерактив — Законы производительности параллельных систем, вводная — Параллельные вычисления. На уровне «железа для всех» — многоядерность.
Принцип Питера
Формулировка (Лоренс Питер, 1969): «В иерархии сотрудник поднимается до уровня своей некомпетентности» — каждый работник повышается по служебной лестнице, пока не достигнет позиции, на которой перестаёт справляться.
В IT это напоминание о двух карьерных треках (инженер vs менеджмент), о риске повышать сильного разработчика в «начальника без управленческих навыков» и о необходимости менторства при смене роли. Не призыв к цинизму — к осознанному подбору компетенций под должность.
Организация команд — методологии и жизненный цикл ПО, роли в интернет-культуре.
Закон Паркинсона
Формулировка (Сирил Паркинсон, 1955): «Work expands so as to fill the time available for its completion» — работа заполняет всё время, отведённое на её выполнение.
В разработке: задача на две недели растягивается на две недели даже если «ядро» делается за три дня — из‑за совещаний, полировки, scope creep. Противоядия — короткие итерации, timebox (спринт), чёткий Definition of Done, приоритизация backlog.
См. планирование конструирования, Agile и Scrum.
Другие «законы» в энциклопедии
| Принцип | Где разобран |
|---|---|
| Закон Конвея — архитектура повторяет структуру коммуникаций | Принципы проектирования |
| Закон Густафсона–Барсиса — альтернатива Амдалу при росте задачи | 4.16 / 7 |
| Хофштадтер — «всё занимает больше времени, чем кажется» | часто рядом с оценками в 7.12 |
Дальше
| Цель | Материал |
|---|---|
| Искать ответы в сети | Эффективный поиск в интернете |
| Мемы и формулы рунета | Рунетские IT-формулы |
| Книги с разбором законов | Подборка литературы (Mythical Man-Month, Cathedral and Bazaar и др.) |
| Форумный этикет | Форумная культура Рунета |