Scrivere software è più facile che leggerlo e capirlo da zero? [chiuso]


12

Io e un mio amico abbiamo discusso ieri delle differenze tra la scrittura di un grande software C ++ e la comprensione come una nuova recluta.

È possibile che dal momento che un software viene eseguito una riga alla volta e questo processo assomigli a come noi (umani) impariamo le cose e costruiamo una cosa sopra un'altra, scrivere un software di grandi dimensioni è in realtà più facile che leggerlo e capire cosa fa (scorrere il codice aiuta ma è necessario ricordare più classi / file di origine insieme non si sa nemmeno per cosa sono stati scritti, il codice multithread aggiunge punti di malus)?

Sembra strano all'inizio, ma dopo aver pensato un po 'sembrava ragionevole


1
Breve spiegazione della chiusura: sebbene questa sia un'ottima domanda, è anche una domanda alla quale non è possibile rispondere, ma solo discussa (ampiamente). Ci sono troppi fattori da considerare, qualità e stile del codice, capacità di apprendimento del lettore e familiarità con il progetto e la lingua, le dimensioni del progetto e così via. Se sei interessato a discutere ulteriormente della chiusura, c'è già una domanda al riguardo sul nostro sito Meta.
yannis,

Il libro "Modelli di apprendistato" parla del viaggio dal novizio al maestro artigiano. Risponde a molte domande di programmatori principianti, apprendisti e giornalisti nella loro crescita professionale. Ci vuole del tempo per usare molti degli schemi ma questo fa parte del viaggio. Uno degli schemi è scrivere "Broken Toys" o "Prototypes" che aiutano a capire e confrontarsi con i sistemi di produzione. Ci sono molti altri schemi utili.
GuruM,

Risposte:


41

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

  1. Lettura del buon codice
  2. Scrivere codice errato
  3. Scrivere un buon codice
  4. Lettura del codice errato

La suddetta classifica porta a 2 conclusioni

  1. Mentre è più facile scrivere codice che leggere codice errato, è più facile leggere codice buono piuttosto che scrivere il proprio codice
  2. Scrivere un codice errato è più semplice che scrivere un buon codice, ma scrivere un codice errato ti prepara a leggere un codice errato, che è la cosa più difficile di tutte. Soprattutto perché il codice errato viene letto più di quanto sia scritto.

Naturalmente, il buon codice e il cattivo codice sono generalizzazioni generali. Raccomando Codice completo e codice pulito per maggiori dettagli sul buon codice.


Molte altre cose possono portare a "codici errati": mancanza di coerenza interna, visione unificante o pianificazione. Una mancanza generale di pianificazione o corretta modularizzazione del codice. Ho visto un buon codice che era inutile perché non utilizzava funzionalità di linguaggio integrate che avrebbero funzionato altrettanto bene.
Ben DeMott,

Inoltre, come scrivere un buon codice: cdn.thenextweb.com/files/2011/01/65987_700b.jpg
CurtisHx

2
Nella mia scala, leggere il codice errato rimane più facile che scrivere un buon codice. Nel peggiore dei casi, è possibile avviare un debugger su codice errato che si sta tentando di leggere o modificarlo con uno strumento di refactoring.
mouviciel,

2
Scrivere un codice errato è facile solo fino al punto in cui deve integrarsi e funzionare, o cambiare rispetto alle mutevoli esigenze. Se "ti programmi in un angolo" non è più facile.
Kaz,

@mouviciel Leggere codici errati scritti da programmatori molto abili che non dovrebbero scrivere codici errati può essere difficile. Leggere codici errati scritti da programmatori ingenui è facile. Basta indossare il "cappello ingenuo" e diventa ovvio ciò che il codice non riesce a provare a realizzare. :)
Kaz,

13

Questa domanda fa appello a un falso consenso. http://en.wikipedia.org/wiki/False-consensus_effect

Diverse persone apprendono e assorbono le informazioni in modo diverso. È simile agli studenti uditivi, agli studenti visivi e agli studenti cinestetici. Per alcuni, leggere il codice è più facile, per altri è più semplice creare codice. Per me è l'ultimo. Per gli altri nella mia squadra, è il primo. Non credo che trovare qualche tipo di consenso o maggioranza sia utile. È meglio capire come il tuo cervello assorbe e impara le informazioni e usa quella conoscenza per migliorare te stesso e imparare ad accettare altri che sono diversi.


1
Sicuramente porre la domanda e sondare l'opinione è molto meglio che semplicemente credere che questa (o qualsiasi altra) ipotesi sia automaticamente corretta. Riconoscere il modo in cui varie persone affrontano lo stesso problema può spesso avere un effetto positivo sul rendimento delle squadre e sul miglioramento delle interazioni sociali.
Robbie Dee,

7
Hai assolutamente ragione. Chiedere è l'inizio. E, capire che esiste un falso consenso è utile per la comprensione. Ecco perché ho "risposto" alla domanda anziché semplicemente ignorarla.
Mawcsco,

7

differenze tra la scrittura di un grande software C ++ e la sua comprensione come nuova assunzione

Questa non è la stessa cosa della differenza tra software di lettura e scrittura. Quando sei nuovo in un progetto (e soprattutto quando sei nuovo in un'azienda) hai molto di 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 collega al resto dell'organizzazione. In breve, la lettura del codice senza il vantaggio della conoscenza di base è un'attività più lenta e più difficile della lettura del codice quando si comprende appieno il contesto in cui il codice funziona.

V'è una differenza tra la scrittura di zecca nuovo codice su un progetto greenfield e la lettura e la modifica di codice esistente, ma non direi che uno è necessariamente più facile rispetto agli altri, solo diverso. Quando crei qualcosa di nuovo, non devi preoccuparti di come far funzionare il tuo codice con ciò che è già lì, ma devi preoccuparti di rendere il tuo progetto sufficientemente estensibile e adattabile affinché rimanga utile in futuro . Quando lavori su un progetto esistente, puoi spesso usare ciò che è già lì come guida, ma devi prima capire cosa c'è.

Come "nuova assunzione" di solito è meglio lavorare su un progetto esistente in particolare perché ti aiuta a imparare tutto ciò che non conosci: come funziona l'azienda, come funzionano i vari progetti, codificando gli standard e le pratiche e persino (soprattutto) cosa potrebbe essere migliorato.


Comprensione dell'ampiezza / profondità del "contesto" del sistema e dell'API sottostante con esperienza. Quali sono i componenti logici del sistema? In che modo questi componenti interagiscono tra loro? Quali meccanismi usano i mattoni sottostanti? Come si comportano i building block sottostanti in percorsi diversi? Quali sono i vincoli / obiettivi del sistema? Perché alcuni percorsi sono stati scelti rispetto ad altri candidati? Se è necessario aggiungere un nuovo componente, cosa è possibile riutilizzare e cosa è necessario aggiungere nuovamente? Riesci a vedere dall'interno del sistema? Un super libro per vedere il pensiero e l'apprendimento pragmatico.
GuruM,

Costruire un "prototipo" o un "giocattolo rotto" (con carenze note e solo per esplorare alternative) contribuirebbe a "costringersi" a pensare alle domande sopra. L'aggiunta di componenti e l'aggiunta di funzionalità seguite da Refactoring aiuterebbero a farsi un'idea dei problemi a portata di mano e delle soluzioni candidate (forse tramite la ricerca nel forum).
GuruM,

4

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

Se sei un veterano, programmatore esperto, è probabile che tu legga il codice e vai "Sì, buona scelta, controlla, oh, avrei potuto fare X invece di Y", ecc. Puoi modificare o modificare, ma risparmia tempo immenso sulla scrittura da zero (a meno che non ci 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 avrai delle inefficienze nel codice. Tuttavia, probabilmente svilupperai una maggiore comprensione della lingua.

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


2

La maggior parte dei programmatori trova più facile capire il codice che hanno scritto loro stessi rispetto al codice che altre persone hanno scritto. Ciò è dovuto sia all'apprendimento integrale che hai citato, sia a una questione di stile e talento individuali. Ecco perché succede così tanta reinvenzione delle ruote.

Tuttavia, questa è la vista degli alberi. La vista foresta è che è molto più facile leggere il codice che scriverlo da zero. Ad esempio, è più semplice 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 molti modi per rendere il codice più semplice da leggere. Trascorri il primo solo tracciando il codice, cercando di capire la superficie del terreno, a volte in un'architettura completamente anatema su come ti piacerebbe farlo. Ma anche in basi di codice molto grandi, passerai forse 40-80 ore a girare le ruote, rispetto alle centinaia di migliaia di ore uomo già investite nella creazione di tale applicazione.


Sai scrivere il codice e non capirlo? Copia forse.
JeffO,

@JeffO Sempre - lol ...
Robbie Dee il

1

La persona che scrive il software avrà quasi sempre la migliore comprensione del programma semplicemente conoscendo la logica e il suo processo di pensiero durante la scrittura.

Non penso che la scrittura del codice possa essere paragonata alla lettura del codice in termini di facilità di comprensione. Da un lato, la semplice scrittura di software fornisce una maggiore comprensione di quel determinato 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 l'effettivo 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 l'utilizzo, il che può portare a semplificarti la vita scrivendo codice.

In termini di conoscenza della build, penso che la lettura del codice e la scrittura del codice siano molto connesse e in molti modi costruite l'una sull'altra. L'esperienza nella scrittura del codice consente di comprendere facilmente il codice degli altri e la lettura del codice consente di semplificare la scrittura del codice (tramite nuovi concetti logici, utilizzo della libreria, ecc.).


1

Questo è qualcosa che personalmente ho sentito evidente, ma non sono mai stato del tutto sicuro che valga per la popolazione della programmazione nel suo insieme. Ad esempio, ho conosciuto alcuni programmatori di grande talento che invece di leggere la documentazione, possono felicemente sfogliare il codice di altre persone e comprenderlo come se fosse il loro.

Questo porta alla domanda: è importante?

Se stai leggendo il codice, è probabile che tu stia apportando una modifica anziché riscriverla. Anche se lo stai riscrivendo, è probabile che tu stia scrivendo questo in una nuova lingua / versione e quindi potresti non necessariamente fabbricare il codice allo stesso modo. Il punto che sto sottolineando è che non è sempre necessario comprendere tutto il codice in ogni momento.

Tutto ciò è vero, le metodologie di sviluppo più recenti, ad esempio BDD , riconoscono che è importante che la logica aziendale sia chiara dal codice piuttosto che dal codice semplicemente come mezzo per guidare la macchina. Questo ovviamente non è una novità: il concetto è in circolazione sin dal lavoro fondamentale di Donald Knuth: Literate Programming .


1

Sono nella risposta di StMotorSpark, aggiungendo solo:
dipende da così tanti fattori che non può essere una domanda sì o no, ad esempio:

  • Il codice esistente è ben documentato e ben scritto o sembra uno spaghetti senza alcun senso o commento?
  • È un'app minuscola con situazioni molto rare che ti costa un tempo infinito per scoprire come risolvere o un'app più grande ma semplice?
  • eccetera.

1
Punti molto buoni; tuttavia, direi che dipende maggiormente dalla persona. Ad esempio, anche se esiste un codice che non ha quasi documentazione, può comunque fornire informazioni sotto forma di "È strano, mi chiedo cosa sia". Se qualcuno vuole davvero imparare, troverà qualcosa di utile indipendentemente dalle dimensioni del programma o della documentazione. Tenendo presente ciò, tuttavia, una buona documentazione e un codice che non sono di dimensioni superiori aiutano sostanzialmente.
StMotorSpark

1
Completamente d'accordo, dipende anche molto dalla persona. Basta notare che, a causa delle esigenze lavorative di alcuni, alcuni di noi fanno molto da zero mentre altri fanno molta manutenzione. Questo inevitabilmente perfezionerà due diverse competenze, indipendentemente dal fatto che entrambe abbiano iniziato con lo stesso modo di pensare ben organizzato, lo stesso livello di logica e comprensione delle specifiche del linguaggio, ...
JoseTeixeira,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.