Коли ж більш продуктивним є побудова власного фреймворку, ніж використання існуючого? [зачинено]

Мені хотілося б знати, чому ви вирішили створити власну структуру у вашій компанії.

Я не маю на увазі мало бібліотек, якими ви користуєтесь часто. Я маю на увазі конкретний спосіб побудови додатків поверх нього, з базовими класами, умовами тощо.

То чому ви побудували власні рамки? Як ви могли б виправдати це людині, яка вас працює. Чи вимірювали ви позитивний та негативний вплив від цього?

Щодо вашого досвіду, чи помічали ви, що в деяких випадках рамки компанії приносять реальні переваги, або, з іншого боку, збільшують витрати на розвиток (крива навчання, налагодження, технічне обслуговування, ...)?

Відповідь на те, чому:

• Проблеми з ліцензією
• Особливі вимоги компанії, які не існували в сучасних рамках
• Компанія хоче мати контроль над підтримкою та підтримкою рамок
• Архітектор не знав кращого! Він / вона не знав про те, що існують конкретні рамки, тому вони вирішили винаходити колесо.

Оновлення:

Підприємства вважають за краще винаходити колесо, а не використовувати "малі" рамки. Малим я маю на увазі рамки, які можуть мати невизначене майбутнє. Наприклад.NET Framework - це більш безпечний вибір для підприємств, ніж рамки, створені малою громадою. Підприємствам потрібна безпека, оскільки багато їх застосування є критичними для бізнесу, а також довго живуть. Витрата на винахід колеса може бути коротшим за короткий термін. Але вартість може бути більшою, якщо рамки, які використовуються в застосуванні компанії, застаріли і більше не підтримуються або змінюються ліцензії. Тут компанії, можливо, доведеться викинути існуючі рамки і поставити ще одну. Visual Basic - хороший приклад мови, яка вже не підтримується Microsoft. А це коштує компаніям мільярди, оскільки їм доведеться починати з нової розробки.

Навіщо будувати своє?

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

Чому б не побудувати свій власний?

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

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

Єдина реальна причина винаходити колесо - це важлива для бізнесу програма. Якщо ваша компанія буде користуватися ще деякий час. Якщо це програми / фреймворк тощо. швидше за все, вийде за рамки існуючих комерційних рамок, що можуть запропонувати, тоді наявність кодерів компаній зробить їх реалізацію, безумовно, прийнятною.

Єдині реальні причини цього:

1. Існуючі рамки доглянуті, повністю відповідають вашим завданням та добре в майбутньому.

2. Це лише випадок синдрому " Не придуманий тут "

3. Ваша поточна установка не зможе успішно створити цю рамку за розумну кількість часу за розумні витрати.

Жоель Спольський написав дуже гарну статтю з цього приводу: « Захист синдрому не придуманого тут»

В основному, коли ви використовуєте роботи інших, ви додаєте їх як невидимих ​​роботодавців або "зайвих рук".

Якщо вони добрі, вони допоможуть вам. Якщо ні, ви повинні виконувати їхню роботу на додаток до власної - іншими словами підтримуйте їх код. Це може бути неприйнятним ризиком, але я вважаю це дуже рідкісним.

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

Тоді я б не вважав, що існує якась причина, щоб не використовувати рамки.

У нас є досить зрілі рамки, де я працюю. Ось короткий опис Основи

Однією з ключових причин його використання є стабільність. Ми не сприймаємо Microsoft чи будь-якого іншого постачальника, який змушує додавати нові функції та складність рік у році.

(Мої власні погляди, а не мої роботодавці тощо.)

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

У більшості випадків ці рамки, вирощені в домашніх умовах, пізніше були видалені новішими, повністю вирощеними структурами. Наприклад, ще в 2000 році я створив веб-рамку Java, в деяких аспектах, порівнянну з Rails, використовував для створення складної системи введення замовлення з кількома голодними формами. Це спрацювало добре, але, звичайно, через кілька років більш зрілі рамки, такі як Струц і JSF, зробили це застарілим. Але тоді це було правильно зробити, він працював добре, і швидкість розвитку була вражаючою.

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