Come ci si sente a proposito dei framework specifici dell'organizzazione?

Quali quadri sono destinati a fare è semplificare, o organizzare lo sviluppo del software in qualche modo che ha beneficio. Sfortunatamente, a meno che la struttura non evolva con nuovi progressi nella lingua, i vantaggi che offre sono probabilmente superati dagli eventi. Ad esempio, 10 anni fa c'erano alcuni framework Java, ma quello che ha la più ampia accettazione è attualmente Spring. Aneddotica, ricordo di aver sentito parlare di Spring e di aver pensato che non arriverò mai da nessuna parte. Ho sbagliato.

È importante capire quale (i) problema (i) il framework avrebbe dovuto affrontare. Se la tua organizzazione deve supportare installazioni di Java di 10 anni per qualsiasi motivo, e la struttura garantisce che il nuovo codice verrà eseguito su macchine virtuali vecchie - questo è un vantaggio importante per l'azienda. Tuttavia, se non ci sono vantaggi di alcun tipo rispetto al vecchio (e forse all'invecchiamento), allora probabilmente dovrai prendere delle statistiche.

Nulla parla ai dirigenti più dei numeri. Quando mostri loro quanto del tuo lavoro è dovuto all'alimentazione della struttura rispetto a quanto tempo ci sarebbe voluto per farlo in un altro modo. Forse sarebbe molto meno politico se ti rivolgessi a una parte specifica del framework che, se cambiata, ti comprerebbe altre x ore di produttività durante il giorno.

I framework devono evolversi nel tempo esattamente come fanno tutti i software. Dato che le nuove funzionalità emergono in una lingua, il quadro deve essere adattato per trarne vantaggio. La primavera di oggi non è certo la primavera quando è stata originariamente introdotta.

Ho visto entrambe le organizzazioni con framework specifici e altre senza.

Avere un framework e attenersi strettamente ad esso significa che ogni programmatore può, almeno in teoria, lavorare su qualsiasi parte di qualsiasi progetto. Questo è un grande vantaggio per una grande organizzazione. Ci sono, ovviamente, almeno due aspetti negativi: a) ad un certo punto nel tempo, diventa obsoleto, ma devi rispettarlo per tutti quei milioni di LOC che lo usano; b) lo usi per ogni progetto, indipendentemente dal fatto che sia o meno adatto; quindi è un martello d'oro (vedi antipatterns)

D'altro canto, le organizzazioni prive di un framework tendono a utilizzare nuovi strumenti per ogni progetto, con una base di codice frammentata che diventa difficile da mantenere. "Oh, il progetto del 2003 ha bisogno di un aggiornamento, dov'è il programmatore VB6? Sh * t, se n'è andato nel 2007!"

Non sorprende che alcune organizzazioni riescano a implementare il peggiore dei due mondi: una struttura interna obsoleta per alcuni progetti, diversi altri strumenti per gli altri progetti.

Molto spesso si creano strutture organizzative perché i framework esterni "non sono stati inventati qui" e altrettanto spesso "Non c'è niente che la corrente soddisfi i nostri bisogni" (cosa abbastanza comune nei primi giorni di J2EE).

• L'organizzazione saggia ha in programma di spostare parti dei propri quadri interni sugli standard del settore (ad es. JPA)

E / O

• L'organizzazione saggia ha in programma di migliorare i propri framework interni per aumentare la produttività degli sviluppatori mantenendo comunque il supporto speciale richiesto

E / O

• Un'organizzazione veramente coraggiosa / illuminata potrebbe aprire parti di origine o tutto il loro framework per mantenerlo aggiornato, pertinente ecc.

La maggior parte delle organizzazioni non fa questo e il commento di ammoQ:

It's no surprise that some organisations manage to implement the worst of both worlds: an outdated in-house framework for some projects, several other tools for the other projects.

È molto adatto:)