La scrittura del software è più semplice della lettura e della comprensione da zero? [chiuso]

In base alla mia esperienza, classificherei le seguenti attività in ordine dal più semplice al più difficile.

1. Leggere il buon codice
2. Scrittura di codice errato
3. Scrittura di un buon codice
4. Lettura del codice errato

La classifica sopra riportata porta a 2 conclusioni

1. Mentre è più facile scrivere codice che leggere codice errato, è più facile leggere codice buono che scrivere il proprio codice
2. Scrivere codice cattivo è più facile che scrivere un buon codice, ma scrivere codice errato ti mette in condizione di leggere il codice errato, che è la cosa più difficile di tutte. Soprattutto perché il codice errato viene letto più di quanto non sia scritto.

Naturalmente, buon codice e codice errato sono generalizzazioni generali. Raccomando Completare codice e Pulisci codice per ulteriori dettagli sul buon codice.

Questa domanda fa appello a un falso consenso. link

Diverse persone imparano e assorbono le informazioni in modo diverso. È simile agli studenti uditivi, agli studenti visivi e ai discenti cinestetici. Per alcuni, leggere il codice è più facile, per altri, la creazione di codice è più facile. Per me, è il secondo. Per gli altri sulla mia squadra, è la prima. Non credo che trovare una qualche forma di consenso o maggioranza sia utile. È meglio capire come il tuo cervello assorbe e impara le informazioni e usa quella conoscenza per migliorarti e per imparare ad accettare gli altri che sono diversi.

differences between writing a large C++ software and understanding it as a new recruit

Questa non è la stessa cosa della differenza tra il software di lettura e scrittura. Quando sei nuovo in un progetto (e soprattutto quando sei nuovo in un'azienda) hai molto più da imparare rispetto a ciò che fa il codice. Capire perché il codice fa quello che fa spesso richiede una comprensione di come funziona l'azienda e di come il progetto si relaziona con il resto dell'organizzazione. In breve, leggere il codice senza il beneficio della conoscenza di base è un compito più lento e più difficile della lettura del codice quando si comprende appieno il contesto in cui il codice funziona.

C'è è una differenza tra scrivere un codice nuovo di zecca su un progetto greenfield e leggendo e modificando il codice esistente, ma non direi che uno è più facile dell'altro, solo diverso. Quando crei qualcosa di nuovo, non devi preoccuparti di come far funzionare il tuo codice con quello che c'è già, ma devi preoccuparti di rendere il tuo progetto sufficientemente estensibile e adattabile da renderlo utile nel futuro . Quando lavori su un progetto esistente, puoi spesso utilizzare ciò che è già presente come guida, ma devi prima capire cosa c'è.

Come "nuova recluta" di solito è meglio lavorare su un progetto esistente in particolare perché ti aiuta a imparare tutte le cose che non conosci: come funziona l'azienda, come i vari progetti lavorano insieme, come standard e pratiche di codifica e anche (soprattutto) cosa potrebbe essere migliorato.

È una domanda interessante, ma tenderei a inclinarmi verso il lato che è più facile da leggere e capire piuttosto che crearlo.

Se sei un veterano, esperto programmatore, probabilmente leggi il codice e vai "Sì, buona scelta, controlla, oh, avrei potuto fare X invece di Y", ecc. Puoi modificare o modificare, ma ciò farebbe risparmiare molto tempo alla scrittura da zero (a meno che non vi siano ragioni per farlo).

Se sei un programmatore più recente, allora "non sai cosa non sai", e quindi dovrai inventare / imparare tutte le piccole cose e molto probabilmente ne avrai alcune inefficienze nel codice. Tuttavia, probabilmente svilupperai una comprensione più approfondita della lingua.

Ma in entrambi i casi, sarà più facile leggere il codice e andare da lì piuttosto che scriverlo completamente da zero.

La maggior parte dei programmatori trova più facile capire il codice che hanno scritto rispetto al codice scritto da altre persone. Ciò è dovuto sia all'apprendimento line-by-line che hai citato, sia alla questione dello stile e del talento individuale. Ecco perché accade così tanto reinvenzione delle ruote.

Tuttavia, questa è la vista degli alberi. La vista foresta è che è molto più semplice leggere il codice che scriverlo da zero. Ad esempio, è più facile scrivere da zero un nuovo elaboratore di testi o imparare abbastanza bene una base di codice esistente per apportare miglioramenti?

Quando inizi a leggere il codice, puoi pensare a mille modi per rendere il codice più facile da leggere per te. Trascorri il primo mentre cerchi il codice, cercando di capire il terreno, a volte in un'architettura completamente anatema su come ti piacerebbe farlo. Ma anche in basi di codice molto grandi, trascorrerai forse 40-80 ore a girare le ruote, rispetto alle centinaia di migliaia di ore di lavoro già investite nella creazione di quell'applicazione.

La persona che scrive il software avrà quasi sempre la migliore comprensione del programma semplicemente perché conosce la logica e il suo modo di pensare mentre lo scrive.

Non penso che scrivere codice possa essere paragonato al codice di lettura in termini di facilità di comprensione. Da un lato, la semplice scrittura del software fornisce una maggiore comprensione di quel particolare software a causa della conoscenza del contesto associato a ciascuna sezione di codice, libreria utilizzata, ecc. Tuttavia, leggere il codice che altri hanno scritto può essere difficile da capire in termini di il vero pezzo di software, ma in termini di comprensione del linguaggio può fornire informazioni su nuovi modi di fare cose o usi di una libreria che potresti non aver preso in considerazione, il che può portare a semplificare il tuo codice di vita.

In termini di conoscenza delle build, penso che leggere codice e scrivere codice siano molto connessi e in molti modi si fondano l'uno sull'altro. L'esperienza di scrittura del codice facilita la comprensione del codice degli altri e il codice di lettura ti consente di scrivere codice in modo più semplice (tramite nuovi concetti logici, utilizzo della libreria, ecc.)

Questo è qualcosa che ho sentito personalmente essere di per sé evidente, ma non sono mai stato del tutto sicuro che ciò sia valido per la popolazione di programmazione nel suo complesso. Ad esempio, ho conosciuto alcuni programmatori di grande talento che, invece di leggere la documentazione, possono prendere felicemente il codice di altre persone e comprenderlo come se fosse il loro.

Questo porta alla domanda: è importante?

Se stai leggendo il codice, è probabile che stai apportando una modifica anziché riscriverla. Anche se lo stai riscrivendo, è probabile che lo stia scrivendo in una nuova lingua / versione e quindi potresti non necessariamente creare il codice nello stesso modo. Il punto che sto facendo è che non è sempre necessario comprendere tutto il codice tutto il tempo.

Tutto ciò è vero, nuove metodologie di sviluppo, ad es. BDD riconoscono che è importante che la logica di business sia chiara dal codice piuttosto che il codice sia semplicemente un significa guidare la macchina. Questo ovviamente non è nuovo - il concetto è stato intorno dal lavoro fondamentale di Donald Knuth: Literate Programming .

Sono nella risposta di StMotorSpark, aggiungendo semplicemente:
Dipende da tanti fattori che non può essere una domanda si o no, ad esempio:

• Il codice esistente è ben documentato e ben scritto o sembra uno spaghetto senza alcun senso o commenti?
• È un'app minuscola con situazioni molto rare che ti costano un tempo infinito per scoprire come soluzione o un'app più grande ma semplice?
• ecc.