Законы IT и программирования: полный справочник
Объединённый справочник — от классических законов программной инженерии до DevOps, UX и мета-законов. С системой взаимосвязей и практическими выводами.
Часть 1: Основополагающие законы разработки
Закон Амдала
Ускорение системы ограничено долей времени, которую нельзя распараллелить. Если программа на 50% последовательна — добавление более 10 процессоров даёт незначительный прирост. Параллелизуема на 95% — улучшения заметны на тысячах процессоров.
Закон Конвея
Организации проектируют системы, копирующие структуру коммуникаций в этих организациях.
Следствие: чтобы изменить архитектуру — меняйте структуру команд. Инверсный закон Конвея: проектируйте команды так, чтобы они производили желаемую архитектуру.
Закон Брукса
Добавление людей к опаздывающему проекту задерживает его ещё больше.
Следствие: не добавляйте людей — сокращайте scope. «Девять женщин не родят ребёнка за месяц.»
Закон Постела (принцип робастности)
Будь либерален в том, что принимаешь, и консервативен в том, что отправляешь.
Основа TCP/IP. API должен быть снисходителен к входящим данным и строг к исходящим.
Закон Кнута о преждевременной оптимизации
Преждевременная оптимизация — корень всех зол (в 97% случаев).
Оптимизируйте только то, что измерено и является узким местом.
Закон Линуса (Linus's Law)
При достаточном количестве глаз все ошибки лежат на поверхности.
Open source + прозрачность кода. Но: критический баг Heartbleed жил в OpenSSL два года — количество глаз ≠ автоматическое обнаружение.
Закон Голла
Работающая сложная система обязательно произошла от работавшей простой. Система, спроектированная с нуля как сложная, никогда не работает.
WWW — классический пример. Не пытайтесь построить сложную систему сразу — начните с простой и эволюционируйте.
Теория разбитых окон
Видимые признаки беспорядка влекут увеличение беспорядка. Плохой код вызывает ощущение, что исправлять бесполезно — и код ухудшается каскадно.
Часть 2: Законы проекта и менеджмента
Закон Паркинсона
Работа заполняет время, отведённое на её выполнение. Устанавливайте жёсткие сроки.
Закон Хофштадтера
Всё всегда занимает больше времени, чем вы ожидаете, даже если вы учитываете закон Хофштадтера.
Рекурсивное определение. Удвойте оценку — а потом удвойте снова.
Закон Гудхарта
Когда показатель становится целью, он перестаёт быть хорошим показателем.
Тесты без утверждений удовлетворяют покрытию кода, KPI искажают поведение.
Закон Парето в программировании
80% времени тратится на 20% кода, 80% ошибок в 20% модулей, 80% пользователей используют 20% функциональности.
Закон Хирша (Hyrum's Law)
С достаточным числом пользователей API любое наблюдаемое поведение системы становится частью контракта.
Вы не можете изменить поведение, если кто-то на него полагается — даже если оно не было задокументировано.
Закон Теслера (сохранения сложности)
Сложность не исчезает, а перемещается.
Переносите сложность на разработчика (простой UX = сложный код) или на пользователя (простой код = сложный UX). Сложность — константа.
Число Данбара
~150 — максимальное количество стабильных социальных связей. При росте команды за этот предел требуются формальные процессы и инструменты.
Часть 3: Законы инфраструктуры и операций
Закон Мёрфи для DevOps
Всё, что может сломаться, сломается — и обычно в 3 ночи пятницы.
Следствие: автоматизация, мониторинг, runbooks.
Закон облачных затрат
Счёт за облако растёт, пока вы не посмотрите на него.
FinOps: отслеживайте расходы еженедельно, ставьте алерты.
Закон сетевой задержки
Скорость света — не предложение, а физический закон.
Любой сигнал имеет фундаментальную задержку. CDN приближает данные к пользователю, но не нарушает физику.
Часть 4: Законы пользовательского опыта (UX)
Закон Фиттса
Время достижения цели пропорционально расстоянию и обратно пропорционально размеру цели. Кнопка «Купить» должна быть большой и близко.
Закон Хика
Время принятия решения логарифмически зависит от количества вариантов. Меньше выборов → быстрее решение. 3 варианта — оптимум.
Закон неустранимой сложности
Каждое приложение имеет неустранимый минимум сложности. Не путайте его с инженерной сложностью, которую можно и нужно снижать.
Часть 5: Мета-законы и философия
Принцип Питера
В иерархии каждый сотрудник поднимается до уровня своей некомпетентности. В IT: отличный разработчик → посредственный менеджер.
Следствие: создавайте параллельные карьерные треки: technical track и management track.
Закон Старджона
90% всего — чушь.
90% кода, 90% статей, 90% стартапов. Но оставшиеся 10% двигают мир.
Закон Каннингема
Лучший способ найти правильный ответ — не задать вопрос, а разместить заведомо неправильный ответ.
Люди охотнее исправляют ошибки, чем помогают.
Бритва Оккама
Не следует множить сущности без необходимости.
Простейшее решение, удовлетворяющее требованиям, почти всегда лучше сложного.
Часть 6: Законы Вышковского (и классические аналоги)
Закон Вышковского (аналог — Закон Вирта)
Софт замедляется быстрее, чем ускоряется железо.
Каждое обновление добавляет функций больше, чем оптимизаций.
Закон обратной совместимости (Раздутого ПО)
Программы растут, чтобы заполнить всю доступную память.
Parkinson's Law of Software: спрос на ресурсы расширяется до их предложения.
Закон критического обновления (Мёрфи)
Фатальный баг приходит в момент жёсткого дедлайна.
Пятница, 17:55, завтра релиз.
Закон техподдержки (Проклятие знания)
Специалист не может понять, почему пользователь не видит очевидного.
Что очевидно разработчику — неочевидно пользователю. Тестируйте на живых людях.
Закон принтера (Подлости)
Техника ломается в самый ответственный момент.
Перед презентацией, перед демо, перед сдачей. Имейте запасной план.
Закон Wi-Fi (Слабых связей)
Сигнал пропадает именно там, где он нужен больше всего.
На созвоне с CEO. На демо инвестору. В самолёте перед дедлайном.
Часть 7: Система взаимосвязей
| Комбинация | Эффект |
|---|---|
| Паркинсон + Конвей | Время тратится на тривиальности, архитектура отражает структуру обсуждений: микросервисы обсуждаются месяцами, монолит не мигрируется никогда |
| Хофштадтер + Брукс | Оценки неверны, но добавление людей только ухудшает |
| Линус + Реальность | При достаточном количестве глаз ошибки лежат на поверхности, но Heartbleed жил два года |
| Теслер + Парето | Сложность константна, 80% усилий — на 20% граничных случаев, которые нельзя упростить |
| Гудхарт + Кнут | Не оптимизируйте, пока не измерили; но когда измерили — метрика искажает поведение |
| Фиттс + Хик | Большие кнопки сокращают путь, но слишком много кнопок увеличивает время выбора |
| Оккам + Теслер | Стремись к простоте, но помни: неустранимая сложность никуда не денется |
| Конвей + Данбар | Архитектура отражает команды; команды > 150 человек требуют формализации |
Часть 8: Практические выводы
Для разработчика
- Профилируй, потом оптимизируй (Кнут, Гудхарт).
- Пиши код для себя через полгода.
- Публичный API — навсегда (Хирш).
- Всё не протестируешь — имей мониторинг и быстрый откат (Мёрфи для DevOps).
Для менеджера
- Добавление людей — крайняя мера (Брукс).
- Без дедлайна результата не будет (Паркинсон).
- Меняй команды, чтобы изменить архитектуру (Конвей).
- Оценки всегда неверны — планируй с буфером (Хофштадтер).
Для бизнеса
- Метрики искажают поведение (Гудхарт).
- Простой UX требует сложного кода (Теслер).
- Сложность нельзя победить — только переместить (Теслер).
- 80% результата — из 20% усилий (Парето).
- Облачные расходы растут незаметно — отслеживайте еженедельно.