"Нужна возможность замены любых классов и методов целиком" Снизит ли это трудоемкость в долгосрочной перспективе?

[mazzy]

Хочу выделить в отдельную тему:

Цитата:

Сообщение от ax_mct

Нужна возможность замены любых классов и методов целиком. Через конфигурационные файлы.

Учитывая стиль ax_mct предлагаю читать не "конфигурационные файлы", а "метаданные". Метаданные могут быть устроены любым удобным способом. Не суть.

Предлагаю обсудить тезис "Нужна возможность замены любых классов и методов целиком"
сразу можно задать тривиальные вопросы: кому нужна? зачем?

но я предлагаю сразу пропустить тривиальные шаги
и подумать над следующим:

Есть стоимость владения - ТСО.
Эта стоимость включает в себя затраты, которые несет купиший продукт на протяжении всей жизни продукта.
Для компьютерных систем это:
= стоимость покупки
= стоимость трудозатрат на доработку
= стоимость трудозатрат на настройку и ввод в экслуатацию
= стоимость трудозатрат во время эксплуатации (пользователям удобно или не удобно => пользователи выполняют операции с меньшими трудозатратами или с большими)
= стоимость трудозатрат на исправление ошибок (пользовательских или программных)
= стоимость трудозатрат на апгрейд продукта на новую версию
= стоимость вывода из эксплуатации и замены на другой продукт

покупатели сравнивают конкурирующие продукты по размеру TCO - чем меньше, тем лучше.

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

но для продукта, который существует на рынке достаточно долго, TCO вполне точно прогнозируемая величина.
======================

теперь собственно к разработке

трудоемкость разработки влияет на TCO в следующих моментах:
= создание новой фичи
= вписывание новой фичи в уже существующий функционал
= кастомизация фичи на конкретном проекте
= изменение/агрпейд уже существующих фич с созданием инструментов апгрейда

======================
так вот... насколько я понимаю, "возможность замены любых классов и методов целиком" уменьшает трудоемкость кастомизации. но сильно увеличивает трудоемкость апгрейда.

а отсутствие возможности "замены любых классов и методов целиком" наоборот, увеличивает трудоемкость кастомизации, но зато уменьшает трудоемкость апгрейда.

собственно см. холивары на тему "открытые/закрытые системы"

======================
собственно вопрос:
Снизит ли "возможность замены любых классов и методов целиком" трудоемкость в долгосрочной перспективе?
Снизит ли TCO?