Какие критерии вы использовали, чтобы определить, следует ли внедрять Software Factory?

Question

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

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

Так что мне интересно (от тех из вас, кто был частью организации, которая внедрила фабрики), это то, что критерий потребуется, чтобы диктовать использование завод в организации, когда риск может быть куча недовольных разработчиков?

Answer 1

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

Также важно (и вполне возможно!) Организовать построенные артефакты с помощью обратных вызовов или других точек расширения; Опять же, ключ в том, чтобы убедиться, что разработчики могут видеть, что ваша работа поддерживает их, а не вытесняет их.

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

Answer 2

В духе SO, IMHO, не существует ни большой, ни малой организации, которая могла бы извлечь больше пользы из Software Factory по сравнению с хорошей средой (Spring, Windsor, Active Record).

Фабрики программного обеспечения интересны только тем, кто строит фабрику, фабричная аналогия очень удачная. В среде SF кодирование может стать повторяющимся и скучным, вы, по сути, говорите своей команде, кстати, вы на самом деле слишком глупы, чтобы понять это, поэтому мы постараемся сделать так, чтобы вы не допустили ошибок. Я знаю, это звучит грубо, но вот как это получается (и да, я был на забавной стороне уравнения, когда мы попробовали это). Согласованность и соглашение могут быть закодированы (я ненавижу принудительно) всеми видами средств, обзор кода лучше, но трудно сделать, анализ кода (FxCop и др.) Хуже, но они охватывают основы.

Другая проблема с подходом SF заключается в том, что когда фабрика не удовлетворяет конкретную потребность, кодеры теряются, они изолированы от базовой технологии до такой степени, что у них нет концептуальной модели того, что происходит. , Это все равно что просить беспилотника производственной линии собрать двигатель, они не знают, с чего начать. С другой стороны, порядочный механик будет знать, что делать (или куда идти). Вы должны расширять возможности своей команды с помощью великолепных инструментов, а не ограничивать их ненужным заводским подходом.