Quando è più produttivo costruire il proprio framework piuttosto che usarne uno esistente? [chiuso]

Vorrei sapere perché hai deciso di costruire il tuo framework nella tua azienda.

Per framework, non intendo poche librerie che usi spesso. Intendo un modo specifico di costruire applicazioni sopra di esso, con classi di base, convenzione, ecc.

Allora perché hai costruito il tuo framework? Come hai potuto giustificarlo alla persona che ti impiega. Hai misurato l'impatto positivo e negativo di esso?

Per quanto riguarda le tue esperienze, hai notato che in alcuni casi un framework aziendale ha prodotto vantaggi reali o, d'altra parte, ha aumentato i costi di sviluppo (curva di apprendimento, debugging, manutenzione, ...)?

Rispondi al perché:

• Problemi di licenza
• Requisiti specifici dell'azienda che non esistevano nei quadri attuali
• La società desidera avere il controllo del supporto e della manutenzione del framework
• L'architetto non sapeva meglio! Non sapeva che esistesse quel quadro specifico, quindi decisero di reinventare la ruota.

Aggiornare:

Le imprese preferiscono reinventare la ruota piuttosto che utilizzare quadri "piccoli". In generale mi riferisco a un quadro che potrebbe avere un futuro incerto. Ad esempio, il framework .NET è più sicuro per le aziende rispetto a un framework creato da una piccola comunità. Le aziende hanno bisogno di sicurezza perché molte delle loro applicazioni sono fondamentali per l'azienda e anche di lunga durata. Il costo per reinventare la ruota potrebbe essere più breve in breve tempo. Ma il costo potrebbe essere maggiore se il framework utilizzato nell'applicazione aziendale è deprecato e non è più supportato o le licenze vengono modificate. Qui la società potrebbe dover buttare via il quadro attuale e inserirne un altro. Visual Basic è un buon esempio di un linguaggio che non è più supportato da Microsoft. E questo è costato alle aziende miliardi poiché devono ricominciare da capo con un nuovo sviluppo.

Perché costruirne uno tuo?

1. perché non è mai stato costruito prima (raro, ma comunque una possibilità)
2. perché vuoi il pieno controllo.
3. perché hai solo bisogno di un po 'di funzionalità in modo che sia più economico costruirlo da solo

Perché non crearne uno tuo?

1. non hai il tempo di farlo
2. è probabilmente molto più economico se acquisti un framework esistente
3. risparmi molto tempo e puoi diventare produttivo molto più velocemente

Nel mio post su quando è opportuno reinventare la ruota, elencherò una serie di vantaggi di una reimplementazione. Penso che questi vantaggi si applichino soprattutto per le librerie di framework. Ad esempio, è spesso impossibile isolare l'uso di una libreria di framework all'interno di una piccola parte dell'applicazione. Al contrario, tendono a dettare la struttura del codice sorgente del client e quindi è desiderabile avere il pieno controllo della libreria.

L'unico vero motivo per reinventare la ruota è se si tratta di un'applicazione business-critical. Se la tua azienda utilizzerà per qualche tempo a venire. Se questo applicazioni / framework / ecc. probabilmente evolverà al di là del quadro commerciale esistente da offrire, quindi avere programmatori aziendali che rendono la loro implementazione è certamente accettabile.

Le uniche vere ragioni contro questo sono se:

1. Il framework esistente è ben mantenuto, si adatta perfettamente al tuo compito e andrà bene anche in futuro.

2. Questo è solo un caso di sindrome di " Non inventato qui "

3. La tua configurazione attuale non sarà in grado di creare con successo questo framework in un ragionevole lasso di tempo a un costo ragionevole.

Joel Spolsky ha scritto un ottimo articolo sull'argomento: In Defense of Not-Invented-Here Syndrome

Fondamentalmente quando usi il lavoro di altri, li aggiungi come datori di lavoro invisibili o "mani extra".

Se sono bravi ti aiuteranno. In caso contrario, devi fare il loro lavoro oltre al tuo, in altre parole mantenere il loro codice. Questo potrebbe essere un rischio inaccettabile, ma lo considero molto raro.

La parola chiave è rendere il framework scambiabile, codificando un'interfaccia. Le interfacce più rigide nel mondo Java sono le specifiche Sun, che è dimostrato dall'API servlet.

Quindi non prenderei in considerazione l'esistenza di alcun motivo per non utilizzare un framework.

Abbiamo un quadro abbastanza maturo in cui lavoro. Ecco un riepilogo di Foundations Framework

Uno dei motivi principali per usarlo è la stabilità. Non siamo tenuti in considerazione da Microsoft o da altri fornitori che sono spinti ad aggiungere nuove funzionalità e complessità anno dopo anno.

(Le mie opinioni, non quelle del mio datore di lavoro, ecc. Ecc.)

L'ho fatto più volte, per soddisfare i requisiti non coperti dai quadri esistenti (allora).

Nella maggior parte dei casi, tali framework sviluppati in casa sono stati successivamente rimossi da framework nuovi e completamente sviluppati. Ad esempio, nel 2000, ho creato un framework Web Java, in alcuni aspetti paragonabile a Rails, utilizzato per creare un sistema complesso di immissione degli ordini con diverse forme complesse. Funzionava bene, ma ovviamente, qualche anno dopo, framework più maturi come Struts e JSF lo rendevano obsoleto. Ma allora, era la cosa giusta da fare, ha funzionato bene e la velocità di sviluppo è stata impressionante.

Un altro framework che ho sviluppato è ancora in uso (e anche in sviluppo attivo); la prima versione è stata scritta nel 2004. Questa è utilizzata principalmente per applicazioni intralogistiche; l'azienda che lo utilizza lo vede ancora come una caratteristica distintiva. Il motivo principale per crearlo è stato quello di semplificare la creazione di applicazioni connesse al database per scanner di codici a barre mobili (con alcune caratteristiche di Windows CE); ha funzionato così bene che i capi hanno deciso di utilizzare lo stesso concetto anche per il software per PC e, beh, ne sono ancora contenti.