Interfacce e astrazione: richiede più tempo?

Il tuo primo paragrafo sembra un caso di ingegneria del software di culto cargo . Solo perché stai creando interfacce e l'utilizzo di DI non creerà un buon programma di progettazione. Basta chiedere a te stesso: quante interfacce hanno solo una classe concreta come implementazione? Le persone che devono cercare l'implementazione di un'interfaccia indicano chiaramente che c'è qualcosa di sbagliato. In molti casi, le interfacce potrebbero essere un'astrazione inutile per il tuo caso aziendale attuale e complicano solo la progettazione.

Una cosa che alza la bandiera rossa è questa linea:

This is all meant as a springboard to test driven development in the (far) future.

C'è così tanto sbagliato in questo tipo di pensiero. Se vuoi fare TDD, fallo dall'inizio. Primo, avere le classi come interfacce non le rende testabili. Soprattutto se stai cercando test che abbiano un senso e non siano un incubo di manutenzione. TDD è inteso come un modo per garantire che il codice sia diviso in parti logiche, che sono logiche da testare. Se, ad esempio, avessi problemi a capire come testare funzionalità specifiche, sarebbe chiaro che il design del codice è sbagliato. C'è un'alta probabilità che, anche con il tuo codice, diventerà problematico creare test unitari per questo. TDD può anche aiutare contro l'astrazione non necessaria che ho menzionato sopra, perché il design della classe sarà abbastanza complesso da soddisfare tutti i requisiti necessari, ma non di più. Qui è un buon esempio.

Per quanto riguarda la mentalità degli altri nei confronti di TDD: questi sono contro-argomenti estremamente comuni e derivano da incomprensioni di TDD e ci sono persino studi che dicono che TDD migliora la qualità del codice, riducendo così i difetti e i costi di manutenzione. Tutto per un aumento del 15-35% nello sviluppo iniziale, che è trascurabile rispetto al tempo risparmiato riducendo i costi di manutenzione.

Per riassumere. Ti consiglio vivamente di smettere di preoccuparti di SOLID e di imparare qualcosa su design OOP e su come applicare TDD.

Alcune cose da tenere a mente:

• Il codice "dividere" e "separare" fa alcune cose. Due: disperde la conoscenza che una volta era concentrata (e che poteva essere letta e compresa in un solo sguardo o in pochi sguardi) e aumenta il vocabolario (a volte, in modo drammatico). Con questo in mente, non "seguire" i principi ". Uno, hanno limiti molto brevi. Due, molte persone prendono "seguendo" come un buon sostituto per consapevolezza e intelligenza - tuttavia, niente batte guardando onestamente cosa sta succedendo e analizzandolo in tutti gli aspetti. Ma con tutti i mezzi, se possibile, mettete alla prova quei limiti, chiarite il suggerimento di esplorare approcci per affrontare i problemi esistenti (e avere sempre un SOLIDO - non il "principio" - il caso per giustificare l'esistenza di questi problemi legati al priorità del progetto), e se la tua squadra è disponibile, c'è molto da imparare a farlo.

• Hai menzionato le classi e le interfacce. Suppongo che tu stia usando un linguaggio con strumenti poveri per fare ciò che intendi. Ciò probabilmente intensifica il proiettile precedente, specialmente per quanto riguarda l'aumento del "vocabolario". I suoi effetti collaterali includono "persone che una volta erano fluenti, non sono più fluenti", "ci vuole più impegno per diventare fluenti" e "occorre più sforzo per dire cosa intendo". C'è altro da dire su questo invece che sulle metafore tra virgolette, ma lascia che concludere questo naturalmente vada contro l'umore umano. E i programmatori felici sono più bravi a risolvere i problemi (attenzione: link alla ricerca empirica).

• Entrambi i richiami di lamentele che hai menzionato sono legittimi. E quello che stai mirando (per quanto riguarda la ricerca di una corretta progettazione e metodologia) è anche legittimo.

• Inoltre, spunti di riflessione: il codice identificato con scarsa qualità per gli occhi è ingannevole (specialmente per quanto riguarda un concetto nebuloso di "qualità"). Ad esempio, i "pasticci locali" (cioè, confinati in una procedura) che sono uniformi e facili da leggere (indipendentemente se irriti gli occhi di una mente legata a un certo modo di organizzare le cose) impongono pochissimo rischio al progetto, di solito avere un'influenza globale nel design del sistema dato il suo isolamento locale (e, per esempio, il codice è rientrante e puro / non ha effetti collaterali esterni) e potrebbe essere molto più accogliente nei cambiamenti. Lo stesso codice refactorato e separato, spesso le volte rendono più difficile leggere, capire e affrontare, perché il numero di "parti mobili" è aumentato e non è chiaro, guardando un elenco di metodi, qual è il loro rapporto, chi è il punto di ingresso, come collaborano, ecc.

Riguardo all'ultimo punto, è molto comune vedere le persone andare fino in fondo con questa separazione (i motivi cambiano con il tempo ma oggi è fatto nel nome di "rendere facile scrivere test unitari"). Allo stesso tempo, alcuni di essi spesso trascurano il risultato finale - notano che la spazzatura degenerata è diventata, esitano, si vede la loro testa pensare "questo non è ... quello che mi aspettavo", ma insistono su di esso; dopo tutto hanno seguito le "migliori pratiche", giusto? E se il risultato è stato soddisfacente con un precedente codice pezzo refactored, anche questo codice refactored dovrebbe essere gradito, giusto? .... anche se è non . Frustrati, molti iniziano a comportarsi come un pendolo, e vanno nella direzione opposta a scrivere un crap code senza pensare dietro e tutto, ma sto divagando.

Quindi, concludendo:

• Scegliere cosa separare, come separare e quando separare è considerevolmente più importante (specialmente, più importante di qualsiasi nozione corrente di estetica Se il claim è "facile da cambiare", dovrebbe essere supportato dal rischio che una determinata sezione di codice sia soggetta a modifiche e quanto o come poco un design contribuisce alla sua economia globale $). In altre parole, questo non è qualcosa che dovrebbe sempre essere fatto, e il risultato sarà sempre buono e redditizio senza il rischio di peggiorare le cose. Pertanto, la costante valutazione e valutazione di benefici, rischi e compromessi precede queste pratiche.

• Se "separare" è argento (e un tipo impuro), "sintetizzare" è oro.