Как бороться с внутренними структурами компании и фабриками ЕО?

Question

Основываясь на своем собственном опыте и опыте моих друзей, я вижу, что у многих компаний есть некоторые странные идеи по разработке собственных фреймворков и SW-фабрик (создающих каркас приложения для вас).Эти идеи обычно основаны на убеждении, что собственная структура будет намного лучше, чем все остальное.Как бороться с такими идеями и как объяснить, что это не всегда хороший путь?

Почему я считаю, что внутренние структуры / фабрики не годятся:

• Бюджет и ресурсы -Обычно есть только некоторый начальный бюджет для создания структуры.Никто не думает о бюджете, необходимом для поддержания и поддержки структуры.Никто не может даже оценить бюджет и ресурсы, необходимые для поддержания.В начале никто не думает о поддержке нескольких версий Framework для поддержки уже существующих приложений.
• Недостаток опыта - Framework обычно создается людьми, не имеющими такого опыта, или при поддержке «консультантов» - как правило, гораздо более дорогих людей.с подобным набором навыков.
• Архитектура / дизайн - любая архитектурная проблема в фреймворке затрагивает все приложения, созданные с использованием этого фреймворка.Плохие решения по проектированию в фреймворке вынуждают разработчиков неправильно кодировать приложения.
• Технический долг - плохой код во фреймворке - это технический долг.
• Ложное убеждение в «серебряной пуле» - менеджеры верят, что собственный каркасФабрика - серебряная пуля.Все приложения будут написаны одинаково и будут легко обслуживаться.Мой опыт показывает, что это просто не правда.Даже с фабрикой ПО каждое приложение является специфическим.
• Недостаточно документации - на первую часть документации влияет низкий бюджет.Рамки без документации бесполезны.Reflector (.NET) - мой лучший друг.
• Недостаточно группы пользователей - внутренняя структура имеет только небольшую группу пользователей.Небольшая группа пользователей означает небольшой опыт.Если я использую общедоступный инструмент или фреймворк и у меня возникла проблема, я могу задать вопрос в SO (или аналогичной сети) или просто попытаться найти ответ в Google.С внутренней структурой это невозможно.
• Политика - политика компании вынуждает вас использовать эту инфраструктуру для оправдания затрат на инфраструктуру.Это заходит так далеко, что рамки выбираются до того, как собраны первые требования.
• Жалобы на рамки запрещены.
• Использование других структур запрещено.

Почему я думаю, что компании делают это:

• Высокомерие и эгоизм - кто-то в компании считает, что он может сделать это лучше.
• Незнание - игнорирование существующих фреймворков / решений и тот факт, что только хорошие фреймворки выжили достаточно долго, чтобы стать популярными.Игнорирование группы пользователей и уже доступной информации в Интернете.
• Ошибка управления и некомпетентность - не понимание влияния (особенно долгосрочного) этого решения.Решение основано на неверной информации.Управление без опыта разработки ПО.

Я понимаю, что иногда требуется собственное решение или среда для специализированных сценариев, но я устал от всех этих "великолепных внутренних структур" для создания веб-приложений или приложений для настольных компьютеров.Я ошибся?Эти фреймворки действительно нужны (мир .NET и Java)?Можете ли вы дать мне пример или причину, почему хорошо иметь внутреннюю структуру / фабрику?

Редактировать:

Спасибо за ответы, но я ожидал несколько советов, как поступитьс проблемой разработчика (кроме смены работы), а не менеджера.

Answer 1

По моему опыту, наиболее распространенной причиной избыточных фреймворков является ... скучающие разработчики !Uninspired разработчики считают, что разработка фреймворков для решения своих проблем гораздо веселее, чем на самом деле решение этих проблем - конечный результат - фреймворки, которые страдают от всего вышеперечисленного (потому что, конечно, разработчик только сделал забавные кусочки), и, возможно, недаже решить реальную проблему (потому что цель состояла в том, чтобы повеселиться, а не решить проблему).

Решение хитрое - трудно понять, что мотивирует разработчиков, так как каждый мотивируется разными вещами,однако мотивированные разработчики, которые заняты тем, что им нравится, не видят, чтобы страдать от этого недуга!

Тем не менее, хорошо продуманные фреймворки при правильном использовании, безусловно, хорошая вещь - Однакоесли он будет использоваться только для внутреннего использования, то лучше вместо этого думать о нем как о расширении ре-факторинга и повторного использования кода, а не как о структуре.

Классический признак того, что кто-то страдает от синдром скучающего разработчика - это когда разрабатывается инфраструктура для решения общего случая , когда еще нет решения для конкретного случая :

• Как узнать, как решитьобщий случай, пока вы не решили хотя бы один конкретный случай?
• Пока вам не пришлось решать общий случай несколько раз, вы только угадываете , что фреймворк необходим даже .

Второй случай, конечно, приводит к наихудшему виду фреймворка - гигантскому универсальному фреймворку, который используется только один раз, для решения проблемы, которая намного проще, чем сама фреймворк.

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

Наконец, постарайтесь не дать разработчикам скучать (в противном случае они попадают во всякое зло!)

Answer 2

Я бы добавил несколько других причин, по которым эти вещи развиваются, и я видел это в нескольких местах: - Блокировка разработчика. Если у вас есть кодирование разработчиков в непередаваемом наборе навыков, им будет сложнее уйти. - Авторская блокировка. Если у вас есть несколько приложений, находящихся в ведении, в зависимости от платформы, у вас есть организация, зависящая от административной группы. - Политический контроль. Централизация позволяет структуре стать каналом политического контроля.

Answer 3

Обобщение плохо, но вот что я заметил, особенно в крупных корпоративных проектах:

• Такое поведение обычно обусловлено одним из немногих инженеров-программистов (обычно они называют себя архитектор программного обеспечения ), которые попадают в описания, которые вы написали в своем вопросе. Каждый должен гордиться чем-то, чтобы иметь мужество проснуться утром. Я добавлю, что по этой причине они обычно используют CV и стараются применять самые последние шаблоны проектирования, не задумываясь о последствиях для бизнеса и окупаемости инвестиций. Ключ НЕ в том, чтобы нанимать такого человека (или пытаться тренировать его / ее, чтобы понять деловые последствия его / ее выбора). Попытка заставить их гордиться тем, что они работают на компанию вместо того, чтобы работать над их структурой, также может помочь.

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

• Удаление рассматриваемого человека в большинстве случаев является плохой вещью, поскольку он СОБСТВЕННО. Поэтому научить его / ее понимать последствия своего выбора, вероятно, является наиболее подходящим способом решения проблемы. Но для этого вам нужен хороший менеджер .

Так что мой единственный совет будет:

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