Regola generale per il costo rispetto al risparmio per il riutilizzo del codice [duplicato]

Obbligatorio XKCD # 974 :

Nella mia esperienza, cercare di rendere sempre tutto riusabile può portare a un eccesso di ingegnerizzazione.

Tuttavia, un certo sforzo non eccessivo per rendere le cose riutilizzabili vale sempre la pena provare a mettere le cose, (quando le cose sono suscettibili di riusabilità), perché un componente riutilizzabile è una componente generale, il che significa che la sua interfaccia è astratto, il che significa che è più facile capirlo da solo, e capire come funziona e perché funziona, e cosa fa e come lo fa, quando lo guardi da solo o quando guardi a esso 6 mesi lungo la strada e non ti ricordi nemmeno di averlo mai scritto. E questi vantaggi sono naturalmente in aggiunta al fatto che è riutilizzabile.

Quindi, per farla breve, credo che la regola generale dovrebbe essere:

Rendilo riutilizzabile se così facendo renderà la sua interfaccia e / o la sua implementazione più facile da capire.

What is a good rule of thumb for spending extra time on analysis and design on project components that have "some probability" of being needed later down the road for other things that may or may need this part.

Per casi come sopra le mie preferenze si basano su una stima derivata in uno dei miei progetti precedenti: il codice riutilizzabile richiede 3-4 volte più sforzi per scrivere (YMMV).

• Un'altra cosa che ho notato è che è piuttosto difficile progettare correttamente il codice da riutilizzare quando tutto ciò che hai è solo un esempio di utilizzo. In altre parole, quando progetto "per ogni evenienza", senza avere un esempio per questo, spesso si scopre che devo ridisegnarlo più tardi quando sorge il bisogno di riutilizzo reale .

Dato sopra, tendo ad evitare di progettare per il riutilizzo finché non avrò un caso reale per questo. In questo senso, seguo piuttosto strongmente YAGNI . D'altra parte, quando c'è almeno un caso di riutilizzo, cerco di ri-progettare per quello invece di duplicare il codice - anche quando il mio calcolo semplice degli sforzi è ancora a favore della duplicazione ( 2x sforzi contro 3-4x) - indovina questa preferenza ha qualcosa a che fare con considerazioni di ulteriore manutenzione.

For example, if I have the need for project X to do things A, and B. A definitely needs to be written for re-use because it just makes sense to do so. B is very project specific at the moment, and I can hack it all together in a couple days to finish the project on time and give everyone kudos for being a great team, etc. Or if we say, lets spend a whole friggin' 2 weeks figuring out what project Y/Z might need this thing for and spend a load of extra time on on part B because someday we might need to use it on project Y/Z (where the savings will be realized).

Nel caso in cui, come sopra, effettuerei personalmente un attacco rapido per B .

L'unica cosa che mi mette a disagio sarebbe se non ci fossero tracce lasciate per questa decisione (come qual è il problema, quali opzioni sono state considerate, quale è stata la decisione e perché). Ma questo è veramente facile da gestire - lo faccio regolarmente in decisioni del genere: registralo nel tuo tracker dei problemi , descrivi cose e lascia che sia lì fino a quando il tempo non ti permette di prendertene cura. O finché non c'è tempo per prepararlo altro progetto Y/Z - quando puoi includere friggin '2 settimane nella stima.

• Numero 1234 - codice throwaway nella cosa B - fix postponed - gli sforzi stimano 2 settimane

La migliore pratica è scrivere un codice pulito e comprensibile a prescindere dai fini del riutilizzo. Un buon codice scritto può sempre trovare il suo posto nel futuro. Non è necessario scrivere codice in modo specifico in base al riutilizzo. Tutto ciò che devi fare è seguire i principi del buon design e un po 'di codice di auto-documentazione. Questo renderà il tuo codice riutilizzabile.

Come hai già fatto notare, viene giù per bilanciare. In termini scientifici / economici, valuteresti i due lati della tua decisione, codice riutilizzabile rispetto a quello specifico per app e riassumi i costi ei benefici di ciascuna parte e tenga anche conto di eventuali valori di probabilità (ad esempio la possibilità che il codice sia effettivamente essere necessario altrove). In realtà, eseguiamo questi calcoli in modo inconscio (usando il buon senso, l'esperienza, il sentimento istintivo ...) quasi ogni giorno.

Tecnicamente, i nostri progetti dovrebbero essere sempre modulari e riutilizzabili il più possibile, ma ci sono molti casi in cui un "mod" come lo metti, impiegherà mezza giornata a scrivere contro un componente generico a settimana. In tal caso, prenderei in considerazione il principio YAGNI .

D'altra parte, se a) sai che c'è una probabilità dell'80-90% che il codice sarà nuovamente necessario, e ha senso e b) non ci vuole molto più tempo per renderlo riutilizzabile, poi dico avanti e progettazione per riusabilità ... e poi per tutto il resto c'è l'area grigio medio:)

Inoltre, in passato ho avuto successo prendendo la via di mezzo tra i tuoi due approcci. Avevo progetti in cui alcune funzionalità potevano essere rese riutilizzabili dal primo giorno, ma così facendo avrei dovuto sostenere costi aggiuntivi. Così, invece, ho mantenuto tutto il codice locale. Nel lavoro futuro in cui è sorto il bisogno di funzionalità simili, sono tornato a progetti in cui questo lavoro era stato fatto originariamente, e in quel momento ho pagato il costo aggiuntivo di avvolgere quelle classi in un modulo riutilizzabile. Ciò ti offre alcuni vantaggi: 1) non paghi costi aggiuntivi finché non ne hai bisogno e 2) quando successivamente crei un componente riutilizzabile, puoi sfruttare la tua conoscenza di quanto bene il codice originale elaborato in caso specifico dell'app e modifica il suo design come necessario prima di introdurlo nel "mondo".

In alcuni casi, i progetti originali non sono mai stati modificati per utilizzare i nuovi moduli riutilizzabili v2.0 perché il codice originale funzionava già e senza sviluppo attivo non aveva senso modificare quel codice. In altri casi, una volta ottimizzati e migliorati i componenti riutilizzabili, siamo tornati indietro e abbiamo sostituito le implementazioni personalizzate, ma solo dopo che le implementazioni personalizzate richiedevano effettivamente il lavoro da svolgere. Quindi una lezione da tutto questo: anche se "hackerò" o scriverai un codice personalizzato, prendi un'ora o due per trovare un'interfaccia pulita. In futuro, se devi modificare questo codice, quell'interfaccia renderà molto più semplice rimuovere il codice personalizzato e sostituirlo con le chiamate alle librerie.

YAGNI . Rendilo semplice, chiaro e ben coperto dai test unitari.

Se risulta che hai bisogno di riutilizzarlo, refactor se necessario. Se hai buoni test unitari, il refactoring è piuttosto a basso rischio. Inoltre, nella mia esperienza, il codice testabile è abbastanza vicino per essere riutilizzabile comunque. Potrebbe essere necessario aggiungere un punto di estensione o due, ma se il codice è pulito per cominciare, non dovrebbe essere un grosso problema.

Dopo un po 'di codifica cosciente in uno stile generico, invertito dalla dipendenza, diventa davvero semplice. Con il bonus del codice automaticamente riutilizzabile.

Non ho una regola empirica in termini di tempo / sforzo / costo, ma la linea che mi piace usare è "il codice riusabile non è parte di un progetto, è è un progetto. " Questo perché il codice veramente riusabile deve avere un proprio insieme di requisiti ben definito che tenga conto di tutto ciò che verrà utilizzato e potrebbe utilizzarlo in futuro.

Ovviamente, puoi prendere qualsiasi componente che viene scritto come parte di un progetto e renderlo riutilizzabile. Ma la differenza tra qualcosa che è "riutilizzabile" (tra virgolette) e qualcosa che ha davvero il potenziale per essere riutilizzato è se sia in grado o meno di soddisfare i bisogni di più consumatori reali in tutti gli aspetti: flessibilità, considerazioni sulla distribuzione, prestazioni, comportamento, configurabilità, ecc. Il livello di progettazione richiesto per ottenere tutto ciò che essenzialmente rende un pezzo di codice riutilizzabile un progetto a sé stante.