Последний(вроде) принцип - APO
Avoid Premature Optimization

Принцип о том, что сначала нужно делать вэлью, а только потом заниматься улучшайзингом. Еще раз напомню, что все мы - технари работаем на самом деле не для улучшения продукта, а для того, чтобы этот продукт зарабатывал деньги. Капитализм правит балом.

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

На самом деле, если грамотно применять принцип YAGNI, то, скорее всего, до принципа APO даже и не дойдет дело.

Простейший и тупейший пример, почему надо следовать принципу APO - это масштабирование. Вы никогда не будете расширять количество серверов или увеличивать их производительность, пока нагрузка на систему не пробивает в пике и 20% от текущих серверных мощностей.

Ну в самом деле, почему мы не ставим пет-проекты на 10 серверов сразу? Правильно, это нецелесообразно, также и для бизнеса. Прямо сейчас никому не важно, что у вас сортировка пузырьком, работающая на целых 0.0002 секунды дольше, чем сортировка Хоара 😂

#словодня как короткая #быстростатья