Come gestisci la comprensione dell'astrazione nel codice?

Quando guardo una nuova base di codice, mi piace iniziare da un approccio dal basso.
Dove comprendo un file e poi passo all'astrazione successiva.
Ma spesso mi ritrovo a dimenticare cosa sta facendo l'astrazione di livello inferiore.

Quindi sarò a questo punto in cui mi ritroverò in un ciclo quasi infinito di tornare ai file che ho precedentemente compreso appieno e quindi provare a riapprenderli; mentre provo a destreggiarsi con numerose altre astrazioni che si collegano tra loro nella mia testa.

Esiste una strategia migliore per affrontare questa situazione?

Dovrei semplicemente dimenticare i dettagli di livello inferiore e prenderli come un dato? Ma anche allora, molte volte è necessaria una precedente comprensione dell'astrazione di livello inferiore per capire cosa sta facendo l'astrazione attuale.

Programmare concretamente è l'impulso di tirare i dettagli verso di te in modo da poterli inchiodare tutti in un unico posto. Iniziamo tutti da questa parte ed è difficile lasciarsi andare.

Programmare in modo astratto è sicuramente "dimenticare i dettagli di livello inferiore". A volte anche dettagli di alto livello. Allontani i dettagli e lasci che qualcos'altro li affronti. La cosa subdola è che lo fai da sempre. Capisci davvero cosa succede tra print "Hello world"e ciò che appare sullo schermo?

La cosa numero uno da chiedere mentre fai fatica a lasciar andare questi dettagli è un buon nome. Un buon nome ti assicura di non essere sorpreso quando guardi dentro. Questo è il motivo per cui non sei stato sorpreso di aver printmesso qualcosa sullo schermo e non ti importava davvero come. foo "Hello world"sarebbe stata una storia diversa.

Inoltre, i livelli di astrazione dovrebbero essere coerenti. Se sei a un livello che riguarda il calcolo di pi, non dovresti preoccuparti di come visualizzare pi. Quel dettaglio è trapelato in un'astrazione a cui non appartiene.

I dettagli più bassi, più alti o di lato, che non riguardano l'unica cosa a cui sto pensando in questo posto, possono andare via del tutto o almeno nascondersi dietro un buon nome.

Quindi, se stai davvero lottando per rimbalzare da un file all'altro, farò delle probabilità che qualcuno ti abbia bloccato con nomi cattivi o astrazioni che perdono.

Lo risolvo leggendo con le dita. Una volta che ho test decenti su questo pasticcio, mi prendo in giro le responsabilità, do loro nomi chiari che evitano sorprese e lo faccio vedere a qualcun altro per assicurarsi che non stia vivendo in un mondo fantastico.

Apparentemente non sono solo quando si tratta di lavorare in questo modo:

Ogni volta che lavoro su codice sconosciuto, inizio a estrarre metodi. Quando lo faccio, cerco pezzi di codice che posso nominare, quindi estraggo. Anche se finissi per illustrare i metodi che ho estratto in seguito, almeno ho un modo per nascondere temporaneamente i dettagli in modo da poter vedere la struttura generale.

Michael Feathers - Codice arancione

In fondo, ci sono alcuni aggiornamenti su come questo per me ha funzionato ogni quarto dell'anno o giù di lì, penso che siano preziosi.

Buona denominazione. Oppure, se è il codice di qualcun altro, cercare di attribuire nomi / responsabilità basati su nomi persino cattivi sulle classi / funzioni di quel sistema, quindi ha senso nella mia testa. Una volta fatto, le implementazioni di basso livello diventano molto più facili da ricordare.

Questo è tutto quello che ho. Ci sono molti puristi su questo sito che sapranno giurare che dio sa quali schemi o oggetti di qualunque tipo, ma una buona denominazione ti porterà lontano. Ho fatto più che bene da solo creando un codice minimamente documentato / ben chiamato / ben disaccoppiato e non è mai tornato a mordermi, anche se il mio codice è stato usato in molti posti, da molte persone, ma il una cosa che ho fatto nel modo giusto è stato perdere molto tempo con una buona denominazione, buoni commenti e schemi che spiegavano il flusso del mio codice. L'implementazione di basso livello è necessaria per capire se desideri espandere il mio codice in modo approfondito. Il codice ben scritto può essere espanso in modi ragionevoli, quindi è ok che qualcuno o tu non capisca / ricordi le implementazioni di basso livello.

Se sei interessato a un po 'di polemiche sul fatto che le persone nel mio campo originale come me sappiano essere la verità, ma, se ascolti ciò che è scritto qui, imparerai ad essere d'accordo e in disaccordo con questa risposta , continua a leggere:

Ma qui c'è un altro problema: i puristi. Sentirai risposte e ideologie ben formulate che sono ragionevoli e completamente logiche, infatti, non c'è nulla di sbagliato in esse. Ma non devi seguirli, infatti, potrebbero giocare a tuo svantaggio.

I miei amici hanno lavorato con grandi sistemi e ridono di persone che si preoccupano un po 'troppo di convenzioni e schemi e, per una buona ragione, lo farei anch'io - posso trovare il mio ragionamento per questo dal mio principale campo di analisi dei dati, dal momento che non sono uno sviluppatore così esperto: la maggior parte delle cose che pensi contano, non importa e c'è una forte correlazione con il tuo ego in questo senso.Spesso un individuo, a causa del suo ego, avrà ottenuto la conoscenza che molto probabilmente ha frainteso a causa dei suoi pregiudizi che ora sono rafforzati dall'autorità che pensa abbia appena detto "la stessa cosa che ho fatto". Questa è una trappola molto nota in cui non dovresti mai cadere. Questo non significa che non lo stia usando nel modo giusto o per il bene più grande, ma spesso, ciò che queste persone faranno è promettere che qualunque cosa stiano dicendo è il premio d'oro.

Che cosa si può fare?

Spiega il tuo codice a un collega e chiedi se ha senso da un punto di vista di alto livello.

Questo è tutto ciò che conta. Naturalmente chiunque legga il codice di qualcun altro avrà sempre una festa alt-tab per vedere l'implementazione di certe cose, ma non importa, se chiunque legga il tuo codice ha la comprensione di alto livello del tuo sistema e capisce "perché le cose accadono "(di nuovo, senza necessariamente sapere pienamente" come accadono "), allora sei d'oro.

Non sono io che sto dicendo di andare avanti e scrivere codice di merda che non è performante o che non rispetta nulla, ma quello che sto dicendo è:

1) Va bene dimenticare. Con il tempo, migliorerai nel leggere il codice con cui stai lavorando. Se il codice che stai leggendo richiede che tu conosca le implementazioni di basso livello a un buon livello, allora è un codice scritto male e gioca in quello che ho detto prima: un collega ti capisce?

2) Il mondo è pieno di molte persone molto intelligenti che non sono molto intelligenti. Spesso sono anche molto emotivi e sono inclini a rinforzare la tendenza da forze esterne. Sono molto bravi in ​​quello che fanno, ma ciò che dimenticano come attori della diffusione delle informazioni è: le idee / informazioni, anche se supportate dalla "logica", hanno il contesto di chi le invia, che è cruciale per capire se le informazioni sono utili anche a te. Ciò che ha senso per te potrebbe avere senso per gli altri e loro lo adorerebbero, ma le informazioni non dovrebbero essere considerate come assolute e uno, ancora una volta, dovrebbero considerare, o almeno cercare di capire il contesto da cui provengono e verificare contro il suo proprio contesto per vedere se corrisponde. È davvero lo stesso dei miliardari che ci danno questi "pezzi di conoscenza per andare avanti"

In breve: scrivere un codice comprensibile e rendersi conto che è ancora discutibile dove abbiamo bisogno di tanti schemi / classi e raffinerie, come alcuni dicono. Ci sono persone molto intelligenti su entrambi i lati dell'argomento e dovrebbe solo rafforzare l'idea di fare tutto ciò che funziona per il tuo team in modo ragionevole - non rimanere bloccato su piccoli dettagli che non contano, li capirai più tardi, ricorda, vivi in ​​un mondo estremamente competitivo in cui il tempismo è la cosa più importante:

Tempi nel successo delle startup.

Assegna il tuo tempo e le tue risorse in modo significativo e goloso.

Ecco una modifica, 6 mesi dopo:

È stato un viaggio folle. Non avrei mai pensato che solo separazione / buona denominazione e documentazione possano sostanzialmente permetterti di collegare qualsiasi cosa dentro e fuori dalla tua base di codice. Ho dovuto riscrivere un sacco di codice per renderlo più veloce con le nuove modifiche e ne ho fatto una buona parte in 2-3 giorni. Posso tranquillamente dire che non ho seguito SOLID dappertutto a causa della mancanza di conoscenza, né delle migliori pratiche e posso dire che sono nel mio debito tecnico, ma non di molto. Separare, nominare bene e documentare, ti permetterà di cambiare codice in pochissimo tempo quando alla fine ti renderai conto di quanto eri stupido.

Non fraintendetemi: se scrivete il codice strettamente accoppiato, avrete molto dolore, anche se odiate il SOLID, anche se capirlo e applicarlo a un livello base consente un grande disaccoppiamento che, onestamente, è l'unica cosa con cui OOP aiuta davvero. OOP avrebbe dovuto riguardare anche il riutilizzo del codice e mentre ciò accade qua e là, non riesci davvero a riutilizzare molti oggetti che crei, quindi concentrati sull'assicurare che il tuo sistema sia ben separato. Una volta raggiunta la maturità e supponiamo che lo zio Bob arrivi e prenda il comando del tuo progetto, dirà "Ok, è stupido ma almeno tutto è separato, ben definito e documentato, quindi almeno so di cosa si tratta " (Io spero). Per me funziona. Il mio LOC cambia costantemente, ma al momento della scrittura, sono 110k righe di codice, 110k righe di codice performante che funziona in armonia per una singola persona è molto.

Ecco una modifica, 3 mesi dopo, su un codice di 8 mesi che sto refactoring:

Tutto ha un senso. Ora posso prendere ciò che ho scritto allora, concettualmente e riforgiare nuovamente il codice, con nuove idee perché capisco perfettamente cosa sta succedendo e perché funziona a causa degli schemi / buona denominazione e commenti. Ho scritto un po 'di codice molto tempo fa che non mi importava di nominare bene e cose del genere ed è un dolore da affrontare. Ora sto pensando a quale potrebbe essere il prossimo passo per spiegare il mio codice.