Per scrivere o non scrivere: Frameworks [closed]

Sono dalla parte opposta dello spettro di GrandmasterB. Per me, questa è una domanda di acquisto e di costruzione.

Dal mio punto di vista, il mio tempo e impegno possono essere rappresentati da un costo. La domanda diventa allora, quando vi è sufficiente ritorno sugli investimenti per costruire un quadro? (Se sto lavorando per un cliente, penso a queste domande dal punto di vista del cliente.)

Ecco le domande che mi pongo:

• Il framework esiste già?
• Se costruisco questo framework, è qualcosa per cui voglio essere conosciuto? In altre parole, questo quadro è un elemento di differenziazione per me?

Spesso, trovo che la risposta alla seconda domanda sia no. Sto lavorando per un'azienda sanitaria ora. Non hanno il desiderio di essere conosciuti come sviluppatori di un motore di programmazione best-of-breed. Dovrei esternalizzare lo sviluppo e la manutenzione di questo quadro.

Tuttavia, se stiamo parlando di un motore di determinazione dei prezzi, questo è il pane e burro dell'azienda, quindi dovrei sicuramente concentrare le mie energie sulla creazione di un motore eccellente.

La mia regola generale è, se si tratta di un prodotto o di una parte importante del prodotto, renderlo me stesso dove possibile. Se non è la sua funzionalità di base, o sta agendo in supporto di un'azienda (qualcosa usata solo inhouse), impazzisci con i framework.

Molte delle applicazioni che faccio sono investimenti a lungo termine - più di 10 anni, forse - e sono prodotti venduti ai clienti (quindi una mia responsabilità). Quindi essere in grado di "velocemente" andare usando una struttura di terze parti non è rilevante per me come lo sarebbe per qualcuno che fa una dozzina di app all'anno. Quindi non sono generalmente contrario a immergermi nel nocciolo duro e fare il mio. Nel corso della vita del prodotto, poche settimane in più per ottenere un quadro / componente personalizzato non avrà molta importanza. Ma potrebbe significare molto meno mal di testa e meno muri di mattoni dal momento che è stato progettato specificamente per l'applicazione.

Mi sembra che un framework sia una raccolta di librerie. Una volta che ne hai un sacco e ti assicuri che abbiano API coerenti e giochi insieme, li impacchetti e definisci un framework. Ma dovresti assicurarti che tutte le librerie della tua azienda abbiano API coerenti, indipendentemente dal fatto che tu usi la parola F o meno.

I framework tendono a essere scritti 'accidentalmente' quando qualcuno guarda tutto ciò che hanno e dice 'hmmm, questo gruppo di cose può essere utile per gli altri'. Questo a meno che tu non sia un'azienda che spedisce la fonte, o ti è stato esplicitamente chiesto di scrivere un framework. Fare cose per il gusto di fare cose è sempre una cattiva idea in programmazione.

Qualunque cosa tu faccia, assicurati di non reinventare la ruota, specialmente come un quadrato.

Se sei come me, il tuo compito è fornire valore di business nel modo più efficiente possibile, non eseguire il debug e modificare i progetti di animali domestici. Se esiste una struttura ampiamente utilizzata che fa ciò di cui hai bisogno, non perdere tempo a reinventare la ruota, poiché la struttura ampiamente accettata probabilmente lo fa meglio di te. Hanno avuto più tempo, esperienza e risorse per svilupparlo.

Negli ultimi 6 mesi la mia azienda mi ha recentemente scritto 2 diverse applicazioni che fanno un sacco di cose simili. Recentemente mi è stato chiesto di scrivere una terza applicazione simile, e c'è molto spazio per altre applicazioni simili in futuro. Dal momento che nessuno ha sviluppato un framework per la tecnologia proprietaria con cui sto lavorando, ho visto nessuna altra opzione ma per sviluppare il mio framework. Se non svilupperò la mia struttura, passerò molto tempo a ripetermi, e questo sarà uno spreco di tempo e denaro.

Penso che questa sia la chiave per decidere se valga la pena crearne una propria o usare quella di qualcun altro. Se devi sprecare un sacco di soldi nei prossimi anni o costruire un framework, quindi costruisci il framework.

È molto difficile prevedere con precisione come sarebbe una struttura ideale senza aver prima costruito qualcosa. Le raccolte sono generalmente migliori di fondazione soluzioni (grazie per i link caarlos0 ), perché il tuo codice non è costruito su indovina su ciò che vuole il programmatore client, ma l'esperienza effettiva. Leggi: Emergent Design .

Detto questo, ho una sola ragione per costruire il tuo framework: se hai fatto lo stesso lavoro due volte e probabilmente lo farai molte altre volte, e nessuno ha fatto il lavoro per te.

Cerco di ottenere il maggior numero di miglia da framework e strumenti disponibili su qualsiasi nuovo progetto. Dopo che il progetto si è evoluto, forse bruciato per un anno o due, quindi la sostituzione delle parti del quadro che causano più dolore è una scelta ragionevole. A meno che il tuo business plan non sia incentrato sulla creazione di un nuovo framework, non penserei di scriverne uno tuo.

Quando un pezzo di tecnologia fallisce davvero, tengo un elenco di reclami e idee specifici su come dovrebbe essere ridisegnato per funzionare meglio. A breve termine, questo "manifesto" mi dà uno sfogo per le mie frustrazioni mentre utilizzo ancora il framework esistente . A medio termine, mi aiuta a identificare i peggiori punti dolenti in modo da non sprecare energia nel risolvere problemi minori. A lungo termine, il manifesto può diventare un progetto per una sostituzione parziale o completa o un elenco di caratteristiche per la scelta di un nuovo framework.