È normale che un programmatore non abbia al 100% la chiarezza del proprio codice a volte? [chiuso]

No, non è normale ¹ . Almeno, non è normale per i bravi programmatori. Probabilmente è normale per qualcuno che impara a programmare.

Scrivere software non è solo mettere insieme linee di codice finché non funziona. È necessario lavorare consapevolmente per rendere il codice facile da capire. Un programmatore che rispetto molto una volta mi ha detto "che il codice viene letto più volte di quanto non sia scritto" . Mentre ciò dovrebbe essere completamente ovvio, era un fatto di cui non ero a conoscenza fino a quando non me lo ha detto. Gran parte del tuo codice viene scritto una sola volta, forse riscritto una o due volte di più, ma finirai per leggere il codice spesso per tutta la durata del software.

Se trovi che il codice è difficile da capire pochi minuti dopo averlo scritto, è un segnale che il tuo codice è troppo complesso. Smetti di aggiungere codice e trova un modo migliore. Ad esempio, un array a cinque dimensioni non è quasi mai una buona idea. Anche i programmatori veramente intelligenti hanno difficoltà a comprendere una struttura dati così complessa.

Lo stesso programmatore che mi ha parlato della leggibilità del codice ha anche detto "mostrami le tue strutture dati e posso dirti come funziona il tuo codice" . Significato, il buon codice inizia con strutture dati pulite e comprensibili. Se progetti correttamente i tuoi dati, il codice è quasi una preoccupazione secondaria. Certo, questa affermazione è un po 'di iperbole perché il software è ovviamente più di un semplice dato, ma inizia con i dati. Quindi, lavorare sulla creazione di strutture dati pulite e facili da comprendere e il codice sarà notevolmente più facile da capire.

¹ Di sicuro c'è un codice là fuori che è molto complesso e difficile da capire anche dai più intelligenti dei programmatori. Alcuni problemi sono intrinsecamente complessi. Tuttavia, oserei dire che la stragrande maggioranza del codice scritto dalla stragrande maggioranza dei programmatori non è quel tipo di codice.

Ci sono due tipi di questo: 1.) confusione 2.) beata ignoranza

Il primo è negativo e potrebbe scomparire con il tempo e l'esperienza.

Il secondo è buono se i progetti diventano più grandi: se devi ricordare ogni dettaglio di implementazione solo per essere in grado di lavorare con il tuo codice, c'è qualcosa di sbagliato in esso (vedi "nascondere le informazioni").

Ogni sviluppatore dimenticherà come funzionava il codice, quindi lo scrive in un modo che un altro nuovo sviluppatore comprenderà e sarà in grado di mantenerlo senza rompere altre parti del programma a lui sconosciute.

Quindi "non sapere" è in realtà una costante nello sviluppo del software: è solo come o se lo gestisci.

Direi che è più comune di quanto le persone vorrebbero ammettere. Anche Brian Kernighan ha fatto allusione a questo:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Quando guidiamo verso il negozio, facciamo una serie di regolazioni dettagliate delle posizioni dei pedali e del volante. Questo è molto facile in questo momento. Ora, immagina se hai registrato quelle registrazioni su carta e le hai date a un amico che aveva bisogno di indicazioni per il negozio.

Allo stesso modo, ci piace scrivere codice a un livello di astrazione, ma ci piace leggerlo in più livelli più alti di astrazione. Il nostro modo preferito di scrivere e leggere il codice è quindi in conflitto. Ciò significa che rendere il codice di facile lettura è di solito un passo distinto e consapevole, con un diverso insieme di competenze.

Ciò che rende un buon programmatore è quando hanno difficoltà a leggere ciò che hanno appena scritto, creano un'astrazione in quel punto. Un programmatore migliore lo fa più volte, diventando sempre più esigente. Alla fine, i programmatori esperti iniziano più avanti lungo il processo, ma spesso possono ancora vedere margini di miglioramento dopo aver letto ciò che hanno appena scritto.

Penso che questo sia qualcosa che andrà via con esperienza.

Se stai scrivendo sistemi complessi, devi avere la capacità di scrivere codice pulito e gestibile che sia tu in futuro, sia qualcun altro in futuro, possa capire. Quindi, in sostanza, la cosa che stai facendo ora non è scalabile.

Avrai molti momenti in cui stai guardando un codice che hai scritto 6 mesi fa e pensando "che diavolo sta succedendo qui?", ma se succede un giorno dopo aver scritto il codice, devi pensa di 'codice pulito' di più.

Fonte: mai usato un array a 5 dimensioni:)

"Normale" è molto soggettivo, quindi dico: è molto comune, ma dovrebbe essere evitato.

Una delle caratteristiche del "buon codice" (ho sentito dire che esiste qualcosa) è la chiarezza: dovrebbe essere chiaro come i problemi sottostanti gli permettono di essere. Se il problema è complesso, anche il codice sarebbe complesso, ma questa è intrinseca complessità, al contrario della accidentale complessità (ho sentito parlare per la prima volta di questa distinzione in discorso di Rich Hickey ) introdotto dal mis- o non usando gli strumenti, i modelli, le tecniche e le pratiche giuste.

Ci sono casi in cui la mancanza di chiarezza è accettabile anche quando il problema non è molto complesso, ad es. se scrivi un sito promozionale che sai durerà finché durerà la campagna di marketing. Questo è un codice throw-away che non deve essere manutenibile. Per altri (e molti) casi, non è accettabile, perché il mantenimento di tale codice costerà molto. Eppure, è comune.

Related:

• When Understanding means Riscrivere - articolo sul problema della comprensione del codice.
• ML efficace - un lungo discorso su, tra ML / OCaml, su come scrivere il codice per "lettori" ( cioè manutentori): "Favorisci i lettori rispetto agli scrittori". Raccomando di guardarlo indipendentemente dalla lingua che usi.

Non penso che sia normale, ma per programmi molto complessi, come il programma di scacchi che hai citato, penso che sia certamente possibile.

Molti anni fa, quando ero appena uscito dalla scuola di specializzazione (quindi ero ancora relativamente inesperto nello scrivere programmi di grandi dimensioni), scrissi il mio primo vero compilatore. L'analisi è stata semplice, ma poi ho dovuto indirizzarla a quattro diversi set di istruzioni del microprocessore. Intendevo scrivere il compilatore nella sua lingua, quindi ho usato per prima cosa solo le caratteristiche del linguaggio di cui avevo assolutamente bisogno, ho scritto il primo generatore di codice in linguaggio assembly e ho verificato che generasse il codice corretto per il sottoinsieme della lingua. Sono stato quindi in grado di utilizzare il compilatore per compilare se stesso da quel momento in poi e aggiungere le restanti funzioni e usarle anche nel compilatore stesso

Ho quindi scritto i generatori di codice back-end per ciascun microprocessore, e ho verificato che tutti generassero il codice corretto, ma mentre corretto non era molto ottimale. Così ho quindi continuato a scrivere ottimizzatori per ogni generatore di codice.

Quando stavo testando l'output dei generatori di codice dopo aver aggiunto tutta l'ottimizzazione, ero spesso sorpreso dal codice generato dal compilatore. Spesso non era il modo in cui avrei scritto il codice a mano, ma era corretto e piuttosto conciso.

Quando non era ovvio per me come il generatore di codice producesse parte del codice che faceva, ho cercato di seguire la logica a mano ma ci sono state volte in cui ho rinunciato. Se avessi aggiunto un sacco di tracce, sarei stato in grado di seguirlo, ma non mi sono preoccupato perché il codice generato era soddisfacente e avevo bisogno di passare ad altri progetti.

Qui ci sono molte risposte decenti.

Ne ho un paio su questo.

Uno è che se non capisci perché il tuo codice sembra funzionare, allora a) probabilmente no (probabilmente solo sembra come funziona), e b) non hai fatto Non capisco il dominio del problema abbastanza bene quando hai iniziato la codifica, o non hai infranto il dominio del problema in unità più piccole e semplificate prima di iniziare.

L'altra mia opinione è che la vera chiave è usare schemi di buon senso e convenzioni nel codice. Questo è un argomento molto più ampio di quello che un piccolo post può affrontare. Ma cerca una buona letteratura sull'argomento, tra cui alcuni dei vecchi standbys come i libri "Code Complete" e "Writing Solid Code".

I dettagli di implementazione cambiano. L'unica vera costante è l'obiettivo funzionale del codice. Se si scrivono più di una funzione, si dimenticano nel tempo dettagli specifici dell'implementazione granulare. Ma dovresti sicuramente capire come funzionano i pezzi quando li costruisci, e dovresti essere in grado di disegnare un diagramma del tutto e capire come i pezzi lavorano insieme.

Se si utilizzano gli schemi e si seguono le convenzioni di buon senso, sarà molto più facile selezionare i dettagli specifici dell'implementazione quando si guarda di nuovo il codice. O quando qualcuno che non ha mai visto il codice prima lo guarda per la prima volta. Inoltre, seguendo tali convenzioni e schemi nel corso del tempo, i dettagli di implementazione si distingueranno dalle convenzioni e dai modelli stessi, che è un altro fattore che renderà il codice più facile da comprendere.

La maggior parte dei problemi che affrontiamo con il software sono complessi per natura. La progettazione del software è un esercizio di gestione della complessità.

Non lo chiamerei normale , ma può sicuramente succedere. Se ti capita poco dopo aver scritto il pezzo di codice in questione, suppongo che il tuo codice sia inutilmente complesso e debba essere semplificato, o che tu sia semplicemente distratto. :)

Ma se metti via il tuo codice, concentrati su altri progetti e torna indietro dopo settimane, mesi o persino anni, non è una sorpresa che dovrai capire tutto di nuovo.

Ma c'è qualcosa che puoi fare al riguardo. Da quello che dici, sembra che tu non pensi abbastanza al tuo codice mentre lo stai scrivendo, e quindi stai rendendo difficile per te stesso capire cosa sta succedendo. Usa questa conoscenza a tuo vantaggio: Questa è la migliore motivazione per produrre un codice ben strutturato, ben documentato e comprensibile. Sai dell'esperienza di prima mano cosa succede quando non ti prendi cura della qualità del tuo codice. Sapere che dovrebbe renderti un programmatore migliore a lungo termine. Quando collabori su progetti software, i tuoi colleghi ti ringrazieranno per aver prodotto un codice comprensibile. E anche il tasso di difetti del tuo codice migliorerà.