в общем, абстрагируясь от споров, то что я для себя увидел по теме + выводы (без шуток... почти)
1. ооп-парадигма - вершина совеременной теории дизайна программных продуктов (иных мнений не было - да будет так)
2. небольшой %% потерь производительности оо-приложений в критичных случаях можно переписать на устаревших,
но, следовательно, близких к железу технологиях (процедуно на той же технологии, на языке ос, асм, коды - короче до необходимого уровня снижения абстракций)
- при этом появляются риски дестабилизации системы, ну да тут уже никак иначе - не ооп это
3. тредстартерские "проблемы" возможны только при неправильной организации разработки оо-софта, правильно оод раобтает только в условиях полноценно внедренной хр-практики
--
это все с ремесленно-практической точки зрения
повторяясь про отсутствие иных мнений - продвигаем оод/хр на уровне разработки + жесткий контроль итераций в управлении
--
с квази-научной точки зрения
хр - "самоорганизующийся бардак"
без обид
нелинейная функция некоторого набора околопроцессных факторов с ростом сроков "чистого производства" приводит к компактизации общих затрат на сумму итераций до выпуска
причем только в данной отрасли
практическое обоснование - чисто эмпирическое, отсутствие общей научной базы - только набор разрозненных практик (я попробовал и мне помогло. попробуй и ты. упорно, пока не поможет.)
интуитивное обоснование - снижение человеческого фактора в производстве с сопутствующим ростом квалификации кадров обязано привести к повышению качества продукта, соответственно, снижению количества итераций последних стадий
+ четкий контроль на ~rup-управлении
--
вроде бы, для щастья ничего больше и не надо ?..
--
на научные обоснования ссылок никто не кидал - значит для успокоения совести надо искать, найти и успокоиться (или не найти и написать
)