Известные законы мира разработки

Как и любая другая сфера деятельности, мир разработки не лишён интересных и известных правил, принципов и законов. Программисты, разработчики, менеджеры и архитекторы часто упоминают их в разговорах. И как правило, мы склонны делать вид, что понимаем нашего собеседника, в то время как представления не имеем о каком-то Бруксе, Муре или Вирте.

Эти законы состоят из правил, принципов или известных слов великих и вдохновляющих людей мира разработки. В то же время все они интересные и забавные.

В этой статье вы познакомитесь с одними их самых известных законов в мире разработки.

Закон Мёрфи

Наверное, один из самых известных законов, по большей части из-за того, что он применим не только к разработке.

Всё, что может пойти не так, пойдёт не так.

Первый вывод: если программа работает, возможно, не вы её написали.

Второй вывод: язык ругательств — единственный, которым все программисты одинаково хорошо владеют.

Итог: компьютер сделает не то, что вы хотите, а то, что напишете.

Оборонительное программирование, управление версиями, сценарий судного дня (на случай этих проклятых зомби-атак), TDD, MDD и т. д. являются хорошими практиками для защиты от этого закона.

Закон Брукса

Большинство разработчиков рано или поздно — осознанно или не очень — сталкиваются с законом Брукса, который гласит:

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

Если сроки близятся к концу, а проект не готов, простое увеличение количества программистов скорее всего не обернётся ничем хорошим. Анализ уровня эффективности программирования, методики разработки, архитектуры и т. д. с большей вероятностью принесут пользу. Или нет, что означает, что где-то замешан закон Хофштадтера.

Закон Хофштадтера

Этот закон был сформулирован и назван в честь Дугласа Хофштадтера. Он гласит:

Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.

Речь идёт о точной оценке времени, необходимого для выполнения достаточно сложных задач. Рекурсивная природа закона отражает всю трудность оценки задач, несмотря на усилия и понимание сложности задачи.

Поэтому всегда нужно иметь запас времени, прежде чем давать какую-либо оценку.

Закон Конвея

Любой программный продукт отражает организационную структуру, создавшую его.

Или ещё более ясно:

Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникаций в этой организации.

Закон основан на том, что для того, чтобы отдельно взятый модуль ПО работал, несколько авторов должны часто общаться друг с другом. Поэтому структура ПО будет отражать социальные границы организации, которая его создала.

Закон Постела или Принцип надёжности

Будьте консервативны в том, что отправляете, и либеральны в том, что принимаете.

Изначально Джон Постел сформулировал это как принцип, обеспечивающий надёжность реализаций TCP. Также этот принцип воплощён в HTML, что многие называют причиной его успеха или неудачи, смотря кого спросить.

Принцип Парето или Правило 80/20

Для многих явлений 80 % последствий вытекают из 20 % причин.

Этот принцип стоит за печальной истиной — 80 % багов вытекают из 20 % кода.

Иными словами, 20 % сотрудников выполняют 80 % работы в компании. Проблема в том, что не всегда понятно, какие именно 20 %.

Принцип Питера

Довольно удручающий закон, особенно если вы испытали его на собственном опыте.

В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности.

Согласно принципу Питера, человек, работающий в любой иерархической системе, повышается в должности до тех пор, пока не займёт место, на котором он окажется не в состоянии справиться со своими обязанностями, то есть окажется некомпетентным. Этот уровень и называется уровнем некомпетентности данного сотрудника. На этом месте сотрудник «застрянет» и будет находиться до тех пор, пока не покинет систему (то есть не уволится, не умрёт или не выйдет на пенсию).

Принцип Керкгоффса

Криптографическая система должна быть безопасна, даже если о ней известно всё, кроме небольшого фрагмента информации — ключа.

Это главный принцип, лежащий в основе криптографии с публичным ключом.

Закон Линуса

Названный в честь Линуса Торвальдса, создателя Linux, этот закон гласит:

При достаточном количестве наблюдателей ошибки выплывают на поверхность.

Этот закон был описан с помощью известного эссе «Собор и Базар», в котором объясняется разница между двумя свободными моделями разработки ПО:

• Модель Собора, в которой исходный код доступен при каждом релизе, но код, написанный между релизами, доступен только ограниченному кругу разработчиков.
• Модель Базара, в которой код выкладывается в Интернет и доступен каждому.

Вывод: чем доступнее исходный код для публичного тестирования, проверки и экспериментов, тем быстрее будут обнаружены всевозможные баги.

Закон Мура

Мощность компьютеров на единицу стоимости удваивается каждые 24 месяца.

Более популярная версия гласит:

Количество транзисторов интегральной схемы удваивается примерно каждые 18 месяцев.

или

Производительность компьютеров удваивается каждые два года.

Закон Вирта

Программы становятся медленнее куда шустрее, чем компьютеры становятся быстрее.

Как тебе такое, закон Мура?

Правило 90-90

Первые 90 % кода отнимают 90 % времени. Остальные 10 % кода отнимают оставшиеся 90 % времени.

И в итоге получаем 180 %, что подчёркивает сложность оценки времени на разработку.

Принцип оптимизации Кнута

Преждевременная оптимизация — корень всех зол.

Сначала нужно писать код, затем искать узкие места, а затем исправлять их!