Scrittura di codice estensibile o cancellabile [chiuso]

Penso che la stratificazione sia sottovalutata. Vorrei che ci fossero più testi che ne parlassero come punto di progettazione. Stratificare significa porre un'astrazione sopra un'altra astrazione (senza permettere che l'astrazione sottostante passi attraverso).

Un grande esempio di stratificazione molto efficace è quando si cambiano le lingue. Ad esempio, scrivi alcuni SQL su un database SQL e ottieni il vantaggio di milioni di linee di codice senza doverli integrare (ad esempio, non devi sapere a quale linguaggio di programmazione è stato utilizzato implementare SQL)!

I DSL sono un altro grande esempio. A volte la creazione di un nuovo codice sorgente in un DSL dichiarativo è il modo migliore per isolare un livello da un altro (il livello di implementazione DSL).

I nostri linguaggi di programmazione trasportano un sacco di bagagli, ad esempio, fare una nuova operazione di solito ha requisiti specifici della lingua che non sono i requisiti della tua applicazione (per esempio che un new String("foo") dovrebbe essere un oggetto separato da qualsiasi altro oggetto nella tua applicazione, anche altri new String("foo") 's).

Con un layering appropriato possiamo isolare i requisiti essenziali / accidentali / dipendenze / caratteristiche l'uno dall'altro.

Should we be thinking about a style of writing code that is better suited to the contemporary software design and architecture of being agile and user-centric (hence evolving faster compared to business requirements) that incorporates both elements of re-usability and also erasability?

Il problema di fondo con il codice cancellabile o estensibile è la comprensione. Meglio lo sviluppatore (i) capisce il problema che si sta risolvendo e il modo migliore per risolverlo, migliore è la soluzione.

Comprendere non è tanto uno stile di codifica o persino uno stile di progettazione: tutti gli elementi e le tecniche discussi nell'articolo (ad esempio stratificazione, isolamento, composizione, interfacce comuni) sono tecniche comuni. Si tratta di un processo mentale.

Il processo descritto nell'articolo collegato descrive la crescente comprensione dell'autore. L'autore avvia il codice di copia-incolla (passaggio 1), quindi fa un passo indietro e lo consolida in librerie (passaggio 2). Successivamente l'autore condivide il codice comune tra i progetti (passaggio 3), quindi realizza che condividere troppo è un onere di manutenzione e crea livelli di astrazione isolati (passaggio 4), quindi si ripete con parti sempre più grandi (passaggi 5, 6 e 7).

Sebbene i passaggi siano familiari agli sviluppatori, le specifiche non sono così importanti. Sono inclusi per il contesto e per "raccontare una storia". Ciò che è importante è:

1. Alcuni pensieri e progetti in primo piano sono fondamentali ma non smettere di pensare una volta che inizi a programmare. A meno che tu non abbia familiarità con il problema, il tuo design cambierà man mano che ne impari di più.
2. Pertanto, non aver paura di refactoring (e l'eliminazione del codice è solo una sottocategoria di refactoring).
3. Pertanto, crea un codice che ti permetta di effettuare il refactoring. Se non riesci a modificare il codice (ad esempio non lo capisci o è troppo fragile (ad esempio manca di test automatici)), rimarrai bloccato con disegni scadenti.

L'autore fa alcuni buoni spunti lungo il percorso, come cercare errori e risolverli invece di creare soluzioni alternative ingombranti.