Ответ заключается в следующем вопросе: вам платят за результат, который достигнут в срок или за качество, которое достигнуто с опозданием? Печально, но программистам (как и переводчикам) платят за скорость написания кода, а не за его качество и скорость выполнения. Если скорость выполнения программы вполне приемлема (не идеальна, а приемлема), то, скорее всего, заказчика это устроит. Если заказчику необходим быстро работающий код, то он явно укажет это в задании, но даже в этом случае, сначала будет написана работоспособная программа и лишь потом она будет оптимизироваться по быстродействию. Иначе, программа может не быть написана вообще! Вот именно поэтому код стоит писать быстро. И только, если он будет неприемлемо медленный, его нужно будет переделать (оптимизировать), и, возможно, делать это будете не вы, а программисты, которые специализируются на подобного рода задачах. Есть над чем задуматься?
shreck заказчика как правило интересует результат, или конечный продукт, ему нет дела до того, как ты там пишешь - на функциях, используя ООП, правильно или неправильно. Он не вникает в суть этих дебрей. В основном ему нужно быстро получить то, что он хочет. И естественно по ходу тестирования он убеждается, что все работает так, как ему надо, или делает тебе предъявы. И как правило оптимизация идет после написания кода
можно писать и быстро и качественно. все упирается в опыт и, как ни странно, в воспитание и культуру программирования, чего у мнооогих нету и в помине.
оптимизация возникает в том случае, когда ИЗНАЧАЛЬНО не правильно просчитана нагрузка на проект и кривая архитектура. во скажите мне, кто в ТЗ указывает пиковые нагрузки на сайт/систему? кол-во пользователей объемы данных? в 99% никто, а потом когда вместо 10 пользователей при тестах завидится 100000 и объем информации вырастает по Тб, все удивляются "почему вусе тормозит?". хехе
shreck Итеративный подход + рулит. И заказчик доволен и видит буквально "сразу", что происходит с его заказом и исполнителю хорошо...