E 'normale aver bisogno di tempo per capire il codice che ho scritto di recente [chiuso]

È normale, ma esistono contromisure comprovate.

Allenati a documentare tutto il tuo codice non throwaway come se fosse lo stavi pubblicando per altri programmatori esperti (ma non per i manichini). Fallo mentre scrivi il codice, parte del processo; rivederlo mentre cambi il codice. Tu sarà praticamente un altro programmatore quando lo hai lasciato da solo per, diciamo, le tue vacanze estive.

Quando si forma questa abitudine, non sembra una resistenza.

La documentazione del codice è un'arma chiave del design, la risoluzione dei problemi e rilevamento dei bug. Quando non puoi codificarlo correttamente, smetti di provare e documentalo per primo Se il codice odora, documentalo e probabilmente vedrai da dove viene l'odore.

Quindi procedi a documentarlo prima comunque .

Scrivi un codice sufficientemente ben progettato e modularizzato rispetto alla documentazione delle interfacce è quasi tutta la documentazione che è necessario scrivere: funzioni, modelli, classi, metodi; parametri e valori di ritorno; pre-condizioni e post-condizioni; eccezioni.

Vuoi che l'implementazione di un'interfaccia sia rilevabile in un "occhio" e "ovvio" a programmatori esperti. Se trovi la necessità di spiegare una implementazione da un commento corrente di commenti, quindi dal design e / o dall'implementazione è cattivo. Le implementazioni intelligenti hanno sempre bisogno di spiegazioni e raramente ne valgono la pena.

Se hai del codice tu hai scritto che fatichi a capire ogni volta che ne hai bisogno per mantenerlo, considera che un bug che ha bisogno di essere risolto, e risolverlo almeno con Correzioni prima del principio .

È "normale" per una definizione normale, ma è anche qualcosa che dovresti cercare di migliorare.

Definisco i miei progressi come un buon programmatore in termini di esattamente questo: quanto facilmente comprendo il mio codice quando lo guardo più tardi ... e in una certa misura, quanto mi scuso nei commenti al mio sé futuro perché so sarà difficile da capire (il codice precedente è triste).

Di solito scrivo molto pochi commenti nel codice che scrivo, dal momento che ritengo che il codice dovrebbe essere abbastanza ovvio. I pochi commenti I do write servono ad aiutare la comprensione di me stesso o di chiunque altro che guarda la base di codice (sebbene quest'ultima non sia tanto importante quanto la prima, chiunque altro sarà ha bisogno di molto tempo per diventare così intimo con il codebase come sei).

Come percorso immediato, ti suggerisco di eliminare tutti i commenti nella base di codice, quindi aggiungere commenti fino a quando non capisci, quindi guarda come i tuoi nuovi commenti si confrontano con quelli vecchi.

A volte è inevitabile, ma la leggibilità è uno dei fattori più importanti nella manutenibilità di una base di codice. Puoi cavartela con un codice che solo tu capisci su piccoli progetti con squadre minuscole, ma che non si adatta affatto bene. Pensa ad alto livello, cosa deve ottenere il codice? Deve funzionare e deve essere mantenibile (tranne alcuni rari casi).

Alcune cose da considerare ...

• Se hai problemi a leggere il tuo codice pochi giorni dopo, in che modo gli altri membri del team potranno leggerlo?
• Quando qualcuno deve apportare modifiche a quel codice 6 mesi dopo, l'intento dell'autore originale sarà chiaro? In caso contrario, come si può essere sicuri che eventuali modifiche non avranno conseguenze indesiderate che si sovrappongono in tutto l'intero sistema? (I test aiutano a mitigarlo)
• Il codice ben scritto dovrebbe dare la priorità alla leggibilità (e alla conseguente manutenibilità) rispetto alla semplice soluzione ultra-concisa su un'unica linea per un problema, che nessuno a parte te stesso capirà.
• La stragrande maggioranza del codice non dovrebbe richiedere commenti. Il codice è i commenti. Gli sviluppatori leggono / scrivono il codice, quindi non dovrebbero averne bisogno SE il codice è stato scritto bene (eccetto per le aree in cui la complessità è inevitabile)
• Noi come sviluppatori abbiamo risorse limitate in termini di concentrazione e forza del cervello. I commenti spesso fungono da rumore e possono essere problematici a causa della natura ambigua di molti termini tecnici e del modo in cui le persone li comprendono.
• Sfrutta la peer review. Prima di controllare il codice, chiedi a un altro sviluppatore di dargli una copia e vedere se lo capiscono. In pratica ci vuole molta disciplina per fare tutto questo, spesso è meglio adottarlo come criterio di squadra.

Ora la maggior parte di questo potrebbe non sembrare applicabile dal momento che si è ancora a scuola e troppo spesso lo sviluppo di codice per un corso non assomiglia in alcun modo a come le cose funzionano nel mondo reale; ma puoi ancora applicare molti di questi concetti ... ad es. usa il tuo professore per fare la peer review (la sua opinione è l'unica cosa che conta alla fine comunque?)

Lavorare su cose senza altri feedback degli sviluppatori può essere davvero difficile. Il feedback ci aiuta a imparare e a crescere molto più velocemente. Lavoro per una società molto piccola, ci sono due di noi, in genere lavorano su segmenti separati di progetti, UI contro logica di calcolo back-end. Internet fornisce molte informazioni, ma questo deve essere suddiviso in conoscenza applicata e la transizione può essere difficile. Quindi, siti come questo sono grandiosi per te e per me.

La complessità del codice che scrivi può essere ridotta. Ci sono diversi modi per farlo. Uno è cercando di suddividere funzioni complesse in funzioni più piccole. Prova ad usare i nomi dei metodi che descrivono chiaramente cosa sta facendo il metodo. Ad esempio, invece di un metodo denominato CalcMatDen, chiamalo CalculateMaterialDensity. Se lo fai, una grande funzione diventerà improvvisamente una serie di chiamate a funzioni più piccole e focalizzate. Ora leggendo il codice puoi vedere facilmente cosa fa una funzione di grandi dimensioni e puoi andare direttamente al livello di complessità a cui tieni ...

Un'altra cosa che puoi fare è scrivere un metodo che restituisca un bool per sostituire le dichiarazioni if complesse.

Invece di:

 if (depth > wellSurveyDepth && 
      depth > wellGeometryDepth && 
      depth > wellTemperatures)

Prova a scrivere un metodo in modo che tu possa fare qualcosa del genere:

if (DepthExceedsWellDepths(depth))

Se hai accesso a Pluralsight, c'è un ottimo corso chiamato Clean Code: Writing Code for Humans di Corey House. Anche il libro Clean Code di Robert C. Martin può aiutare. Nota a margine, scrivere Test unitari può essere molto utile quando si lavora per scrivere un codice più gestibile.