Как работать с внутренними структурами компаний и фабриками SW?

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

Почему я думаю, что внутренние фреймворки/фабрики не очень хороши:

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

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

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

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

Edit:

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

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

Такое поведение, как правило, управляется одним из немногих инженеров-программистов (они обычно называют themselve software architect), которые попадают в описания, которые вы написали в своем вопросе. Каждый должен гордиться чем-то, чтобы иметь мужество просыпаться утром. Я добавлю, что они, как правило, основаны на CV по этой причине и пытаются применять последние шаблоны проектирования, не думая о бизнес-значимости и рентабельности инвестиций. Ключ НЕ нанимать такого человека (или попытаться обучить его/ее понять бизнес-последствия его/ее выбора). Попытка заставить их гордиться работой в компании, а не работой над их инфраструктурой, тоже может помочь.
Пропущенные сроки, ошибки, высокий оборот, как правило, решаются путем применения причудливых методологий (обычно плохо реализованных), таких как scrum или нанятых высокооплачиваемых консультантов, которые ухудшат ситуацию... вместо того, чтобы удалять (или коучинг ) лиц, которые не должны были наняты на первом месте.
Удаление человека, о котором идет речь, в большинстве случаев является плохим, поскольку он СОБСТВЕННЫЙ. Поэтому научите его/ее понимать последствия его/ее выбора, вероятно, наиболее подходящим способом решения проблемы. Но для этого вам нужен хороший менеджер.

Поэтому мой единственный совет:

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

Ответ 3

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