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

Rispondi al motivo:

• Problemi di licenza
• Requisiti specifici dell'azienda che non esistevano negli attuali framework
• L'azienda vuole avere il controllo sul supporto e sulla manutenzione del framework
• L'architetto non lo sapeva meglio! Lui / lei non sapeva di quel quadro specifico esistito, così hanno deciso di reinventare la ruota.

Aggiornamento:

Le aziende preferiscono reinventare la ruota piuttosto che usare strutture "piccole". Per piccolo mi riferisco a un quadro che potrebbe avere un futuro incerto. Ad esempio, il framework .NET è più sicuro per le imprese rispetto a un framework creato da una piccola comunità. Le aziende hanno bisogno di sicurezza perché molte delle loro applicazioni sono business critical e anche longevo . Il costo di reinventare la ruota potrebbe essere più breve. Ma il costo potrebbe essere maggiore se il framework utilizzato nell'applicazione aziendale è deprecato e non più supportato o le licenze vengono cambiate. Qui la compagnia potrebbe dover eliminare la struttura attuale e inserirne un'altra. Visual Basic è un buon esempio di un linguaggio che non è più supportato da Microsoft. E questo costa alle aziende miliardi dal momento che devono ricominciare con un nuovo sviluppo.

Perché costruisci il tuo?

1. perché non è mai stato creato prima (rara, ma comunque una possibilità)
2. perché vuoi il pieno controllo.
3. perché hai bisogno solo di un po 'di funzionalità, quindi è più economico crearlo da solo

Perché non costruisci il tuo?

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

In il mio post su quando è appropriato per reinventare la ruota elenco una serie di vantaggi di una reimplementazione. Penso che questi vantaggi si applichino specialmente 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. Invece, tendono a dettare la struttura del codice sorgente del client, e quindi è desiderabile avere controllo completo sulla libreria.

L'unica vera ragione per reinventare la ruota è se si tratta di un'applicazione business-critical. Se la tua azienda verrà utilizzata per un po 'di tempo a venire. Se questa applicazione / framework / ecc. probabilmente si evolverà al di là del quadro commerciale esistente, quindi avere programmatori aziendali renderà la loro implementazione certamente accettabile.

Gli unici veri motivi contro questo sono se:

1. Il framework esistente va bene mantenuto, si adatta perfettamente al tuo compito, e andrà bene nel futuro.

2. Questo è solo un caso di " sindrome non trovata qui "

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

Joel Spolsky ha scritto un ottimo articolo sull'argomento: In difesa della sindrome non inventata qui

Fondamentalmente quando usi il lavoro degli altri, li aggiungi come datori di lavoro invisibili o "mani in più".

Se sono bravi ti aiuteranno. Se no, devi fare il loro lavoro in aggiunta al tuo - in altre parole, mantieni il loro codice. Questo potrebbe essere un rischio inaccettabile, ma lo considererei molto raro.

La parola chiave è di rendere il framework scambiabile, mediante la codifica su un'interfaccia. Le interfacce più rigide nel mondo Java sono le specifiche Sun, che sono dimostrate dall'API del servlet.

Quindi non considererei alcuna ragione per non utilizzare un framework.

Abbiamo una struttura piuttosto matura in cui lavoro. Ecco un riassunto Framework delle fondazioni

Uno dei motivi principali per utilizzarlo è la stabilità. Non siamo grati a Microsoft o ad altri fornitori che sono spinti ad aggiungere nuove funzionalità e complessità anno dopo anno.

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

L'ho fatto più volte, per soddisfare requisiti non coperti da framework esistenti (allora).

Nella maggior parte dei casi, questi quadri interni sono stati successivamente rimossi da strutture più recenti e completamente sviluppate. Ad esempio, nel 2000, ho creato un framework web Java, in alcuni aspetti paragonabile a Rails, utilizzato per creare un sistema di inserimento ordini complesso con diverse forme hundered. Ha funzionato bene, ma naturalmente, alcuni anni dopo, framework più maturi come Struts e JSF l'hanno reso obsoleto. Ma a quei tempi, era la cosa giusta da fare, funzionava bene e la velocità di sviluppo era impressionante.

Un altro framework che ho sviluppato è ancora in uso (e anche in sviluppo attivo); la prima versione fu scritta nel 2004. Questo è principalmente usato per applicazioni intralogistiche; la compagnia che lo usa lo vede ancora come una caratteristica distintiva. La ragione principale per crearlo è stata semplificare la creazione di applicazioni connesse al database per gli scanner di codici a barre mobili (con alcune funzionalità 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.