Когда более продуктивно создать собственную платформу, чем использовать существующую? [закрыто]

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

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

Итак, почему вы создали свой собственный фреймворк? Как вы могли бы оправдать это человеку, который вас нанимает. Вы измерили положительное и отрицательное влияние этого?

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

Ответьте почему:

• Проблемы с лицензией
• Специфичные для компании требования, которых не было в существующих рамках
• Компания хочет иметь контроль над поддержкой и обслуживанием структуры
• Архитектор не знал лучше! Он / она не знал об этой конкретной структуре, поэтому они решили заново изобрести колесо.

Обновить:

Предприятия предпочитают изобретать велосипед, а не использовать «маленькие» рамки. Под маленьким я ссылаюсь на рамки, которые могут иметь неопределенное будущее. Например, платформа .NET более безопасна для предприятий, чем среда, созданная небольшим сообществом. Предприятиям нужна безопасность, потому что многие их приложения критически важны для бизнеса, а также долговечны, Стоимость переизобретения колеса может быть больше в короткие сроки. Но стоимость может быть больше, если среда, используемая в приложении компании, устарела и больше не поддерживается, или лицензии изменены. Здесь компании, возможно, придется выбросить существующую структуру и вставить другую. Visual Basic является хорошим примером языка, который больше не поддерживается Microsoft. И это обходится компаниям в миллиарды, поскольку им приходится начинать все сначала с новой разработки.

Зачем строить свой?

1. потому что он никогда не был построен раньше (редко, но, тем не менее, возможно)
2. потому что вы хотите полный контроль.
3. потому что вам нужно только немного функциональности, чтобы дешевле было построить его самостоятельно

Почему бы не построить свой собственный?

1. у тебя нет времени на это
2. это, вероятно, намного дешевле, если вы покупаете существующий каркас
3. Вы экономите много времени и можете работать намного быстрее

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

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

Единственные реальные причины против этого, если:

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

2. Это всего лишь случай синдрома « Не изобретено здесь »

3. Ваша текущая установка не сможет успешно создать этот фреймворк за разумное время и за разумную цену.

Джоэл Спольски написал очень хорошую статью по этому вопросу: в защиту синдрома «не изобретено-здесь»

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

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

Ключевое слово - сделать фреймворк сменным, кодируя интерфейс. Наиболее жесткими интерфейсами в мире Java являются спецификации Sun, что подтверждается сервлетом API.

Тогда я бы не стал считать, что есть причина не использовать фреймворк.

У нас есть довольно зрелые рамки, в которых я работаю. Вот краткое изложение Основ Основы

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

(Мои собственные взгляды, а не мнения моего работодателя и т. Д. И т. Д.)

Я делал это несколько раз, чтобы удовлетворить требования, не предусмотренные существующими структурами (тогда).

В большинстве случаев эти доморощенные фреймворки впоследствии были удалены новыми, полностью вырастившими фреймворками. Например, еще в 2000 году я создал веб-фреймворк Java, в некоторых аспектах сравнимый с Rails, который использовался для создания сложной системы ввода заказов с несколькими упорядоченными формами. Это работало хорошо, но, конечно, через несколько лет более зрелые фреймворки, такие как Struts и JSF, сделали его устаревшим. Но тогда это было правильно, это работало хорошо, и скорость разработки была впечатляющей.

Другой фреймворк, который я разработал, все еще используется (и также находится в активной разработке); первая версия была написана в 2004 году. Эта версия в основном используется для интралогистических приложений; компания, которая его использует, по-прежнему считает ее отличительной чертой. Основная причина его создания заключалась в том, чтобы упростить создание приложений, связанных с базой данных, для мобильных сканеров штрих-кода (работающих под управлением Windows CE); это сработало настолько хорошо, что боссы решили использовать ту же концепцию и для программного обеспечения для ПК, и, ну, они все еще довольны этим.