Конфигурябельность

[@SergeyT]

ок. Убрал.

[@Smi1e]

Статья просто о жизни и взаимоотношениях разработчиков с заказчиками в контексте одной конкретной проблемы — конфигурабельности.

[@SergeyT]

Одной из идей статьи является проектирование; выбор того или иного решения в контексте конкретной задачи, вот и запостил в «Проектирование и рефакторинг». Если есть идеи, где это дело будет уместнее опубликовать: велкам! С радостью перенесу.

[@SergeyT]

В мире разработки ПО происходит отвратительно мало новых событий. Если знать нормальные источники, то найти там себя проблем абсолютно не составит. Так что да, такое происходит, причем достаточно часто.

[@Zaboday]

А я много новых слов узнал. Спасибо.

[@Bambr]

Довольно распространенный сценарий. Я обычно прибегаю к тактике «бодание заказчика», когда вижу задачу, которая способна заметно усилить связи между подсистемами проекта — на мой взгляд, это одна из самых больших бед, существующих в коде, т.к. от нее чрезвычайно трудно избавляться, а избавляться часто приходится именно в процессе рефакторинга. Расчет простой — если заказчику фича нужна как воздух, он меня порвет и фича будет. Если же он и сам не уверен, зачем ему это нужно — я уберегу проект от излишнего внутреннего усложнения.

[@MAD_Kolia]

Читаешь как школьное сочинение. Единственное — сюжет взрослый.
Прочитал, но не понравилось. Не моё.

[@norguhtar]

Работа по scrum вообще не подразумевает отдачу микроменеджмента заказчику. Это лишь средство повышения прозрачности процесса разработки ПО между разработчиками и заказчиком. По сути дела все sprint необходимы в первую очередь заказчику и по этому ему должны быть пронятны все задачи в scrum. К примеру писать сделать загрузчик классов через relfection туда писать не надо. Оно ничего не даст заказчику. Он должен видеть там вещи вида «создание заявки», «отслеживание заявки», «поиск заявки» и т.п. Ну а про конфигурябельность я вам могу предложить посмотреть в сторону DI фреймворков реализующих данную концепцию под C# имеется.