Законы программирования

https://habr.com/ru/post/491946
Перевод репозитория github.com/dwmkerr/hacker-laws

Технологии и методы повышения качества работ часто приходят из IT и для этого есть объективные причины. Любопытно посмотреть на существующие «Законы программирования» с точки зрения процессов управления компанией, в том числе формирования стратегии. Приеду особенно понравившиеся:

Теория разбитых окон утверждает, что видимые признаки преступлений (или отсутствие заботы об окружающей среде) влечёт за собой увеличение количества и тяжести преступлений (и дальнейшее ухудшение окружающей среды). Теория неоднократно подвергалась критике. Однако по личному опыту работы в группе хорошо структурированный обмен информацией между участниками значительно повышает мотивацию в процессе совместной работы. Верно и обратное - плохое «набрасывание данных» расхолаживает. Если вы ведете конспект беседы плохим почерком, то впоследствии у вас меньше желания расшифровывать его и использовать в дальнейшей работе.
Закон Брукса говорит о том, что во многих случаях попытки ускорить выпуск проекта, который и так опаздывает, путём добавления к нему дополнительных людей, приводят к тому, что проект выпускают ещё позже, чем могли бы. Учитывая затраты на время, необходимое на ввод в строй новых ресурсов, и на общение людей между собой, в краткосрочной перспективе скорость развития проекта падает. Также многие задачи могут не подлежать разделению, то есть, их не получается легко распределить между ресурсами, количество которых увеличили, поэтому потенциальное увеличение скорости оказывается не таким значительным. Неочевидное следствие этой проблемы заключается в том, что при разделении команды на более мелкие группы, эффективность таких групп обычно растет. Видимо, в результате более тонкой фокусировки задач и ответственности.
Закон Голла говорит о том, что попытки разработать очень сложную систему наверняка провалятся. Системы высокой сложности редко создают за один присест – они эволюционируют из более простых. Работающая сложная система обязательно произошла от работавшей простой системы. Сложная система, разработанная с нуля, никогда не работает, и её невозможно исправить так, чтобы она заработала. Нужно начать заново, с простой работающей системы.
Цикл шумихи – визуализация восторгов и развития технологии со временем, изначально построенная компанией Gartner. После появления технологии её популярность доходит до пика раздутых ожиданий, затем ныряет во впадину разочарования, поднимается по склону просветления и выходит на плато продуктивности. Мы склонны переоценивать влияние технологии в краткосрочной перспективе и недооценивать его в долгосрочной.
Преждевременная оптимизация. Дональд Кнутв в работе «Структурированное программирование с GoTo» писал: «Программисты тратят огромное количество времени на размышления и волнения по поводу скорости выполнения некритичных частей программ, и попытки сделать их эффективнее оказывают сильный негативный эффект, если задуматься об их отладке и поддержке. Нам нужно забывать о малозначимой эффективности 97% времени: преждевременная оптимизация – корень всех зол. Однако в критических важных 3% случаев мы не должны упускать наши возможности». Преждевременную оптимизацию также можно описать, как попытку оптимизировать что-то до того, как мы поймём, что нам нужно сделать.
Закон протекающих абстракций. Этот закон утверждает, что абстракции, которые обычно используются для упрощения работы со сложными системами, в определённых ситуациях дают «протечку», пропуская наверх элементы лежащих в их основе систем, из-за чего абстракция начинает вести себя непредсказуемо.
Закон тривиальности утверждает, что группы тратят гораздо больше времени и внимания на обсуждения косметических или тривиальных проблем, чем на серьёзные и обширные.
Принцип единственной ответственности. Каждый объект должен иметь одну ответственность и эта ответственность должна быть полностью инкапсулирована в класс. Принцип утверждает, что каждый модуль или класс должен делать только одну вещь. На практике это значит, что небольшое единственное изменение функции программы должно потребовать изменения только в одном компоненте. Теоретически это придаёт коду надёжности и упрощает его изменение.
Принцип KISS. Keep it simple, stupid [Не усложняй, дурик] Принцип KISS говорит, что большинство систем работают лучше, если их не усложнять; следовательно, простота должна быть ключевой целью в разработке, а ненужной сложности нужно избегать. Зародился он в военно-морском флоте США в 1960, и фразу приписывают авиаконструктору Кларенсу Джонсону.
YAGNI. Акроним для You Ain't Gonna Need It [вам это не понадобится].
Всегда реализуйте функции только тогда, когда они вам реально нужны, а не тогда, когда вам кажется, что они вам понадобятся в будущем.