Показать сообщение отдельно
Старый 21.03.2017, 14:38   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
"Нужна возможность замены любых классов и методов целиком" Снизит ли это трудоемкость в долгосрочной перспективе?
Хочу выделить в отдельную тему:

Цитата:
Сообщение от ax_mct Посмотреть сообщение
Нужна возможность замены любых классов и методов целиком. Через конфигурационные файлы.
Учитывая стиль ax_mct предлагаю читать не "конфигурационные файлы", а "метаданные". Метаданные могут быть устроены любым удобным способом. Не суть.

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

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

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

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

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

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

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

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

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

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

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

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