Come affrontare la filosofia del riutilizzo del codice?

Mi ritrovo costantemente a pensare al riutilizzo del codice all'avvio di un nuovo progetto.

In che misura devo rendere riutilizzabile il mio codice?
Devo limitarlo all'ambito dell'applicazione o devo renderlo riutilizzabile al di fuori del progetto?

A volte, penso che la riusabilità del codice possa ostacolare un design semplice. Per favore, condividi la tua comprensione e il tuo approccio alla riusabilità del codice.

Il codice deve funzionare prima di poter essere riutilizzato. Ciò implica che la progettazione e la funzione (primaria) dovrebbero venire prima della considerazione del riutilizzo del codice.

È bene pensare a riutilizzare e riutilizzare i componenti che hai già scritto. Ma a volte può essere altrettanto veloce, se non più veloce, solo scrivere il codice e farlo funzionare. Dopo aver risolto il problema originale, è possibile riformattare il codice per renderlo più riutilizzabile.

Ricorda il KISS e YAGNI:

Codice re-usability better to be considereduna volta pronto il documento di progettazione . Questo ti permetterà di vedere la sezione / parti del codice che saranno potenzialmente duplicate.

Quindi, quando non hai un design chiaro, applica l' approccio KISS e YAGNI nel tuo lavoro!

Questo è dalla mia esperienza, ma credo ancora che possa essere applicato e segue le linee di ciò che GlenH7 ha menzionato.

Lavoro tra 3 aziende realizzando vari progetti. Le aziende sono sorelle l'una dell'altra con alcune pratiche standard e metodologie di lavoro, ma sono anche uniche in molti modi. Detto questo, generalmente inizio ogni progetto fresco e voglio solo farlo o mostrare progressi. Quindi, se mi imbatto in uno scenario in cui ricordo un pezzo di codice o funzionalità che ho scritto per un progetto precedente, farò una delle due cose (dipendente dal tempo):

1. Metodo più veloce
   Copia il codice precedente dall'altro progetto (non hai molto tempo) nel mio progetto attuale.

2. Secondo metodo più veloce
   Copia il codice precedente e inseriscilo in una libreria comune, quindi includi quella libreria nel progetto corrente (per facilitare l'avanzamento).

   2b. Se apporto delle modifiche all'altro progetto (originale), lo refatterò per utilizzare la nuova libreria [ma generalmente non lo farò a meno che non debba toccare nuovamente quel progetto].

Basta essere avvisati, testare il diavolo dalle biblioteche comuni. Librerie comuni significano creare dipendenze. Le dipendenze creano punti di fallimento. Anche se potresti aver bisogno di qualcosa di leggermente modificato per la tua attuale implementazione, non sai come cambierà qualsiasi altra cosa usando quella libreria.

A volte trovo che copiare e incollare poche righe di codice sia una soluzione migliore. Anche nel linguaggio umano, quando vuoi dire una frase che hai detto prima solo con una leggera variazione, la ripeterai con la variazione, perché crea meno problemi a chiunque.

Tuttavia, se il tuo modulo di grandi dimensioni deve essere utilizzato in un modo leggermente diverso da quello che non supporta, non clonarlo solo per modificare poche righe perché è molto probabile che vorrai estendere la funzionalità che sia la base che il clonare share in futuro. Invece, rendilo configurabile o esporta la funzionalità che sia la base che il clone condividono in un altro modulo che entrambi useranno.

Non esagerare. E se non sei sicuro, mantieni l'ambito dell'applicazione fino a quando non avrai scritto abbastanza progetti per vedere dove puoi riutilizzare cosa.