Обычно под преждевременной оптимизацией имеют в виду переоптимизации в коде, который находится не на критическом пути, или микрооптимизации типа x = (x * 0xCCCCCCCD) >> 35, которые обычно вредны. И что, разумеется, нужно ориентироваться на бенчмарки.

Недавно я столкнулся с недопониманием от коллеги. Я указал на область в коде, где у нас был регресс несколько релизов подряд, и высказал гипотезу, что там проблемы с полнотой и качеством модели. Код там достаточно запутанный — не удивительно, что если в одном месте починить, то в другом может внезапно поломаться. При этом оригинальная задача, на мой взгляд, вполне может быть выражена чистой функцией, пусть и с очень большим количеством входов. Однако, по уверению коллеги, это непозволительная роскошь: код должен работать быстро, поэтому он так и выглядит.

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

В целом, “наоптимизироваться” можно на уровне операции, структур данных (когда людям жалко лишнее поле добавить, например), алгоритма, модели. Еще можно добавить архитектуру. И конечно, не стоит забывать про самую лучшую оптимизацию, на уровне задачи — тут большой простор от “мы это делать не будем” до “мы строим космический корабль, чтобы полтора землекопа в носу поковырялись продуктивнее”:)