Come fai a sapere che stai scrivendo un buon codice? [duplicare]

Il più grande indizio per me è:

Quando devi tornare indietro e aggiungere / modificare una funzionalità, è difficile? Rompi costantemente le funzionalità esistenti quando apporti modifiche?

Se la risposta a quanto sopra è "sì", probabilmente hai un design generale scadente.

È (almeno per me) un po 'difficile giudicare un design fino a quando non è richiesto di rispondere al cambiamento (naturalmente, alcuni codici sono solo cattivi e lo si può capire subito, ma anche quello viene fornito con esperienza .)

Questa è certamente una misura abbastanza standard in cui lavoro.

Which door represents your code? Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are customers leaving in droves and managers breathing down our necks...

(Robert C Martin, Pulisci codice - libro che si apre con l'immagine sopra)

Sai che stai scrivendo un buon codice quando:

• Le cose sono intelligenti, ma non troppo intelligenti
• Gli algoritmi sono ottimali, sia in termini di velocità che di leggibilità
• Classi, variabili e funzioni sono ben definiti e hanno senso senza dover pensare troppo
• Torni su di esso dopo un fine settimana, e puoi saltare direttamente in
• Le cose che saranno riutilizzate sono riutilizzabili
• I test unitari sono facili da scrivere

Anche se hai detto che non hai altri programmatori in giro per farlo, lo includerò per il bene degli altri.

Il test sulla qualità del codice: hai un altro programmatore che non ha mai visto il codice leggerlo e spiega cosa ti fa ogni modulo mentre guardi alle spalle. Più strong è la tua voglia di entrare e spiegare qualcosa, il peggio è probabilmente il codice. Se riesci a sederti tranquillamente con la bocca chiusa e non hai bisogno di fare un sacco di domande, probabilmente sei bravo.

Per il tuo beneficio, ecco alcune linee guida generali per quando non hai un peer a portata di mano. Non sono assoluti, solo "odori".

Buoni segni

• I metodi tendono ad essere molto brevi che idealmente eseguono un singolo compito.
• Hai abbastanza informazioni per chiamare i metodi senza guardare il loro corpo.
• I test unitari sono facili da scrivere.

Segnali danneggiati

• Metodi lunghi costituiti da 2-3 sotto-attività che non sono suddivisi in altri metodi.
• I metodi condividono i dati con mezzi diversi dalla loro interfaccia.
• Se si modifica l'implementazione di un metodo (ma non l'interfaccia) è necessario modificare l'implementazione di altri metodi.
• Un sacco di commenti, in particolare commenti a lungo termine.
• Hai codice che non viene mai eseguito nella tua applicazione per fornire "flessibilità futura"
• Grandi blocchi try / catch
• Hai difficoltà a trovare i nomi dei metodi validi o contengono le parole "OR" e "AND" (ad esempio, GetInvoiceOrCustomer)
• Blocchi di codice identici o quasi identici.

Ecco una lista più lunga di odori di codice che dovrebbe essere utile.

Per me personalmente, penso che sia quando dimentico il codice. In altre parole:

• Si verificano raramente errori
• Quando si verificano, altre persone li risolvono senza chiedermi nulla
• Ancora più importante, nessuno mai mi chiede nulla riguardo al mio codice
• Le persone non hanno un alto tasso di WTF / min durante la lettura
• Molte nuove classi nel sistema iniziano a usare la mia classe ( fan-in , come la chiamerebbe Steve McConnell)
• Il codice è facile da modificare e / o refactoring quando / se necessario, senza maledirmi (anche se sono io - maledicimi!)
• Mi piace anche quando indovino la giusta quantità di astrazione che sembra essere adatta a tutti nel team

È una bella sensazione quando apri un file che hai scritto un anno fa e vedi tutte le belle aggiunte in una classe, ma pochissime modifiche , e - fan-in molto alto! :)

Naturalmente, queste sono le cose che mi fanno me come se stessi scrivendo un buon codice, ma in realtà è molto difficile sapere. La mia ipotesi è che se le persone iniziano a prendere in giro il tuo codice più di quanto ti prendono in giro, è il momento di preoccuparti.

Ho tre regole d'oro:

1. Se mi sento in dovere di copiare / incollare blocchi di codice, sto facendo qualcosa di sbagliato
2. Se non riesco a prendere l'intero codice nella mia testa, sto facendo qualcosa di sbagliato
3. Se qualcuno salta dentro e si perde nel mio codice, sto facendo qualcosa di sbagliato

Queste regole mi hanno guidato a fare dei veri miglioramenti architettonici, finendo con classi / metodi piccoli, puliti e mantenibili.

Questa è una domanda eccellente, e ti applaudo anche per averlo chiesto.

Per prima cosa, è bello che la tua mente venga soffiata ogni tanto. Ti tiene umile, ti fa capire che non sapere tutto, che ci sono persone migliori di te e che ti dà qualcosa di meglio per cui lottare.

Ora, come fai a sapere quando stai scrivendo un buon codice?

• Quando le tue classi hanno ciascuna un unico scopo ben definito, separate dalle altre classi con altri scopi chiaramente definiti.
• Quando i tuoi metodi sono brevi - idealmente sotto le 50 righe e certamente sotto i 100 - e i loro nomi definiscono chiaramente cosa fanno esattamente . Un metodo non dovrebbe fare nulla se non quello che implica il nome. Se stai andando oltre 100 linee, o inserito a schede molto lontano, puoi probabilmente estrarre qualcosa nella sua funzione.
• Quando il codice fornisce un modo per fare qualcosa - quando non fornisce l'opzione di zig o zag, ma invece fornisce un singolo percorso lineare per ogni possibile linea di azione che l'utente può inviare.
• Quando hai fatto tutto ciò che è ragionevolmente possibile per ridurre l'accoppiamento tra le classi; in modo che se la Classe A dipende dalla Classe B, e la Classe B viene rimossa e la Classe C viene inserita nella sua posizione, non è necessario apportare alcuna modifica alla Classe A. La Classe A dovrebbe essere il più cieca possibile a quello che sta succedendo nel mondo esterno.
• Quando i nomi delle classi, dei metodi e delle variabili possono essere letti e compresi immediatamente da chiunque incontri il codice, non è necessario 'pktSize' quando 'packetSize' legge molto più facilmente.

Come altri hanno detto, in sostanza, se stai facendo programmazione orientata agli oggetti, e quando arriva il momento di cambiare qualcosa, lo trovi come cercare di districare e riavvolgere un gomitolo di lana, il codice non segue un buon oggetto -Principi orientati.

Consiglio vivamente il libro "Pulisci il codice", se sei interessato a scavare un po 'più avanti Questo. È una buona lettura sia per i principianti che per gli esperti.

Direi che i miei punti principali sarebbero:

• Readability (per te e chiunque altro abbia esaminato il tuo codice)
• Manutenibilità (facile da modificare)
• Semplicità (non complicare le cose quando non ce n'è bisogno)
• Efficienza (ovviamente il tuo codice dovrebbe essere eseguito velocemente)
• Chiarezza (se il tuo codice è auto-esplicativo, non c'è bisogno di commenti per la maggior parte del tempo, rinomina i tuoi metodi / proprietà ecc. sensibilmente, rompi il lungo codice, non copiare mai e incolla un blocco di codice)

Non inserisco Design in questo elenco poiché credo che un buon codice possa essere scritto senza attenersi a un modello di progettazione purché sia coerente all'interno del progetto.

Un buon articolo di MSDN su questo argomento: Cosa rende buono il buon codice?

Cerca un buon progetto open source nella tua lingua preferita e guarda cosa fanno.

Ad esempio, sendmail è un posto dove cercare se scrivi codice spaghetti . Non è colpa di sendmail in realtà; ha solo 20 anni quindi ha un sacco di cruft. Quindi se il tuo codice sembra come il codice sendmail, probabilmente sei sulla strada sbagliata.

Non ho guardato Postfix ultimamente a me stesso, e probabilmente è molto ben progettato. Quindi se la tua roba sembra più come postfix sei sulla strada giusta.

Quando ho iniziato a programmare da bambino non c'era Internet e non avevi nulla da confrontare. Ma ora con un migliaio di righe di codice disponibili per la comparazione, dovresti iniziare a farti un'idea se lo stai facendo giusto o no.

E solo perché il kernel Linux è il kernel di Linux non significa che sia ben scritto. Tienilo a mente.

Questa è stata la mia esperienza dal passaggio dal mondo universitario della programmazione all'industria negli ultimi cinque mesi:

• La facilità d'uso è così importante che paghiamo le persone solo per progettare interfacce utente. I coder spesso assorbono la progettazione dell'interfaccia utente.
• Ci si accorge che non è sufficiente farlo funzionare
• Le ottimizzazioni diventano più importanti negli scenari del mondo reale.
• Ci sono mille modi per affrontare un problema. Tuttavia, spesso l'approccio non tiene conto di fattori leggermente meno noti che potrebbero influire negativamente sulle prestazioni del tuo approccio come l'autenticazione del database, le transazioni, il file I / O , reflection, solo per nominarne alcuni casuali.
• La manutenibilità è un aspetto molto importante della codifica. Solo perché il tuo codice è ottimizzato e super denso ... non significa che sia sexy. A volte è semplicemente etichettato come "Codice eroe".
• Le abilità di progettazione sono apprese, non inerenti. Sono sicuro che ci sono alcuni bambini cerebrali là fuori, ma in generale, un solido design rispetto ai problemi del mondo reale, è fatto attraverso il tempo, l'investigazione e, soprattutto, la trasmissione della conoscenza dai tuoi superiori = P
• La documentazione non è una comodità, è una necessità.
• La stessa cosa vale per test delle unità (questo varia da azienda a società)

Suggerirei di cogliere un'opportunità con un progetto open source. Avrai la possibilità di vedere quanto sai veramente se lavori con altri programmatori. Un progetto open source è probabilmente il modo migliore per scoprirlo in base al tuo background.

Quando puoi leggerlo come una prosa.

Dal punto di vista del codice e del design, mi piace quello che altri hanno già detto sulla manutenibilità.

Inoltre, guardo anche alla stabilità. Guarda le statistiche di supporto alla produzione. Se stai ricevendo un'alta istanza di corrispondenza di supporto per cose che sembrano funzionalità fondamentali ma stai scoprendo che molte persone non sono in grado di capire come utilizzare il software o se non lo soddisfano, allora c'è qualcosa di sbagliato.

Ovviamente, ci sono alcuni utenti che sono veramente incapaci, ma se nel corso del tempo si continuano a ricevere segnalazioni di rotture, confusione o richieste significative di modifica delle caratteristiche, allora si tratta di una o tutte le seguenti condizioni:

• I requisiti sono stati infranti
• Il codice è rotto
• L'applicazione non è intuitiva
• Lo sviluppatore non ha capito che l'utente ha bisogno di
• Qualcuno ha spinto per data di consegna rispetto alla qualità
• Qualcuno non ha testato bene o sa cosa testare per

Leggi il buon codice e scopri perché è buono. Leggi il codice errato e scopri perché è cattivo. Leggi il codice mediocre e scopri quali parti sono buone, quali sono cattive e quali sono ok. Leggi il tuo codice e fai lo stesso. Raccogli un paio di libri di testo (ben considerati) appositamente allo scopo di esaminare gli esempi e capire perché li hanno scritti come hanno fatto. Per lo più, leggi il codice fino a quando non riesci a distinguere tra il bene e il male e puoi fare il tuo "Wtf"? test.

Non puoi sapere se stai scrivendo un buon codice finché non puoi riconoscere un buon codice in generale. Solo perché qualcosa è sopra la tua testa non significa che sia ben scritto ...

("Leggi il codice di altre persone" è apparso in un paio di commenti su questo thread, ma ho pensato che meritasse il suo stesso post)

Chiedi a qualcun altro di prendere in consegna il tuo lavoro per un giorno e controlla quanto stressato è alla fine della giornata; -)

Non sono bravo a documentare e ripulire le cose, quindi è così che lo controllo.

That all being said, I feel like I never know if my programs are any good. Sure, they work - but is the code clean, tight, well-written stuff, or would another coder look at it and slap me in the head?

Hai considerato chiedendo a un altro codificatore cosa pensano del tuo codice?

Alcuni luoghi utilizzano la "peer review" in cui il codice deve essere accettabile per un altro codificatore prima che venga accettato nel repository del codice.

IMHO, non c'è "buon codice" di per sé, ma c'è "buon software".

Quando stiamo lavorando su qualcosa, ci sono molti vincoli sul nostro lavoro, che molte volte ci farebbero produrre il codice che rientra nello standard di "buon codice" di altri colleghi programmatori.

Alcuni potrebbero dire che "codice buono" è il codice che è facile da mantenere. La controargomentazione per questa affermazione per me è, quanto è facile? Abbiamo bisogno di dedicare uno sforzo del 200% al pezzo di codice per renderlo così facile da mantenere per lo standard "buono codice", anche se sappiamo che non avremo bisogno di mantenerlo così tanto? Mi dispiace ma non credo.

In effetti, sono io che promuovo veramente "buon codice" nella mia squadra che a nessuno importa davvero. Ogni volta che guardo i loro codici, non ho mai trovato che scrivono un codice perfetto. Tuttavia, devo accettare che hanno davvero svolto il lavoro e che sono anche in grado di mantenerlo adeguatamente per le esigenze della nostra azienda. Ovviamente l'applicazione è a volte buggy, ma ce l'abbiamo fatta in tempo, rendendo felici i nostri clienti e utenti e assicurando la nostra azienda nella posizione molto più avanti rispetto ai nostri concorrenti.

Quindi, direi che "codice buono" è il codice che produce ciò di cui hai bisogno. Devi solo pensare a ciò di cui hai veramente bisogno, quindi usarlo per valutare il tuo codice.

Il buon codice è soggettivo per la persona. Un programmatore professionista che ha letto molti libri ed è stato ai seminari e ha utilizzato tecniche di codifica diverse probabilmente farebbe a pezzi il tuo codice ... Tuttavia, ho trovato che il codice è davvero indicativo di dove si trova il livello di esperienza dei programmatori. Per me si legge come un libro di storia o un'auto-biografia. È ciò che il codificatore sapeva all'epoca o quali strumenti era limitato a lui.

Chiediti questo ... Perché Microsoft prende 3 versioni di software per ottenere qualcosa di giusto? Perché costantemente correggono gli errori che hanno fatto nelle versioni precedenti. So che il mio codice migliora sempre di più dopo una revisione. Certo ci saranno persone qui che dicono, scrivo codice perfetto la prima volta. Se credi che allora ho un terreno paludoso per venderti ...

Come capisci i concetti le cose diventano più facili. Per me, l'inizio di imparare qualcosa di nuovo è "posso farlo funzionare?", Quindi il passo successivo è "Mi chiedo se posso farlo in questo modo ...", quindi di solito quando l'ho inchiodato chiedo "come posso renderlo più veloce" ...

Se vuoi essere un programmatore, devi immergerti e farlo. Ci vuole un sacco di lavoro e ad essere sinceri è come un'opera d'arte che non può mai essere finita. Tuttavia, se vuoi essere solo un hobbista casuale, se funziona, non preoccuparti. Devi adattarti ai tuoi dintorni. Se non hai modo di fare revisioni del codice, l'ignoranza è beat =)

Ma non importa cosa ... Ognuno avrà la propria opinione. Certo, ci sono modi giusti e modi sbagliati di fare le cose ... Ma soprattutto ho scoperto che ci sono modi migliori per fare le cose che solo modi sbagliati ...

Per un particolare pezzo di codice:

Se funziona e è manutenibile (scegli le tue buone pratiche), è un buon codice.

Per te come sviluppatore nel tempo:

Il bene è un termine relativo e dinamico, al dominio della lingua, al dominio del problema, alle tendenze attuali e, soprattutto, alla tua esperienza. Il test acido "BUONO" per questo continuum potrebbe semplicemente guardare indietro al tuo lavoro precedente e se dici " sigh l'ho davvero risolto in questo modo?" allora è probabile che tu stia ancora crescendo e che probabilmente continuerai a scrivere un buon codice.

Se guardi indietro e vedi il codice perfetto allora - sei perfetto, e c'è il rischio che tu stia stagnando e presto potresti smettere di scrivere un buon codice.

Rilascia il tuo codice, fai in modo che alcune persone lo confondano per assicurarsi che faccia ciò che è sempre supposto. O se lo desideri, progetta una specifica e assicurati che soddisfi tutte queste specifiche. Se superi uno o entrambi questi test, allora il tuo codice è "buono per ora". Per la maggior parte delle persone, il tuo codice non sarà mai eccezionale, perché tornerai tra un anno e dirai "Perché ho fatto questo quando avrebbe funzionato molto meglio questo way? "

Con più esperienza, ottieni un codice migliore. Ma se pratichi continuamente le stesse abitudini, cadrai sempre nelle stesse insidie. È solo una semplice versione di un vecchio adagio di "La pratica rende permanente ." Se fai continuamente le cose nel modo giusto (come testare il tuo codice per assicurarti sempre che funzioni per quello che dovrebbe fare), allora migliorerai. Se continui a fare le cose nel modo sbagliato (come non testare il tuo codice per determinate situazioni, o non riuscire a riconoscere dove potrebbero verificarsi errori), ti ritroverai ostinato con il tuo codice.

Non c'è niente di meglio che qualcuno abbia visto guardare il tuo codice, ma ci sono alcune risorse che ti aiutano a valutare e migliorare il tuo codice da solo. Dai un'occhiata a Refactoring di Martin Fowler (o sito ). Gli standard di codifica C ++ di Sutter and Alexandrescu sono buoni se stai scrivendo in C ++. Molte raccomandazioni in questo campo sono indipendenti dal linguaggio, ma altre potrebbero consigliare libri simili per altre lingue. Lo sviluppo guidato dai test può essere molto utile agli sviluppatori solisti, in quanto fornisce una sorta di controllo di qualità, e sai quando i test diventano difficili da scrivere che significa che il tuo codice potrebbe probabilmente utilizzare la ristrutturazione.

Alcuni altri segni sono più orientati al processo. Di solito portano a un codice migliore, ma non direttamente. Questi includono cose come l'uso del controllo del codice sorgente, un processo di compilazione automatizzato, non lo sviluppo direttamente sul server live, l'uso del software di tracciamento dei bug, ecc.

Puoi utilizzare lo strumento di analisi del codice come FindBugs , PMD . Ciò fornirà alcune informazioni sulla qualità del tuo codice.

Nel tentativo di codificare bene, mirano a garantire che il programma sia altamente funzionale e veloce al riguardo. Assicurati che tutto sia a posto in modo che il file, i dati, la funzione e le astrazioni siano abbastanza evidenti.

Dopo questo punto l'ho messo alla prova: trova una persona abbastanza svantaggiata nei computer in generale, prova a spiegare alcuni dei pattern principali del codice. Se possono in qualche modo leggerlo, wow. Bel lavoro.

Per lo più solo KISS e cerca di essere innovativo senza rovinare nulla. Vorrei anche prendere altre note su come tornare al codice e divertirmi a migliorarlo e mantenerlo, ma questo è stato trattato abbastanza bene.

Mai.

"Good code" è solo un codice per il quale non è stato ancora trovato alcun modo di migliorare. Come Jeff Atwood ha detto :

There are a handful of programmers in the world capable of producing brilliant, perfect code. All the rest of us can do is keep making our software less shitty over time-- a process of continuous improvement

E a proposito, non devi raggiungere la perfezione, perché a volte " Design sufficiente significa design scadente ".

Uso 5 punti per sapere se il codice è buono o meno:

• procedura, metodo e nomi di classe sono entrambi utilmente brevi e tuttavia mi dicono cosa fanno.
• il commento su qualsiasi include causa il mancato funzionamento di
• guardando il codice dopo un mese di distanza, posso seguire il flusso
Il codice
• viene compilato e viene eseguito in modo pulito.
Il programma
• esegue le azioni previste e solo le azioni previste.

Per me, GetCustIDFromDB (var & ast, DB, char & cliente;) è migliore di getcid (var & ast; DB, char & ast; c) perché mi dice cosa sto guardando. Ma * DBLookupCIDByName (var & ast; DB, char & ast; customer) funziona anche.

Controllo spesso per vedere se effettivamente uso ancora tutti i miei #inclusi ... Se riesco a rimuoverlo, ottimo. A volte, è possibile esaminare le intestazioni incluse e vedere se le funzioni necessarie sono effettivamente in qualcosa che l'intestazione include tramite #include invece ... ma l'ho fatto solo raramente, e risparmia anche un po 'di spazio anche se potrebbe rendere molto più difficile l'aggiunta di nuove funzionalità.

È una cosa difficile da dire. C'è sempre la questione di impiegare più tempo per farlo nel modo giusto, o impiegare meno tempo e farlo prima, in modo da poter lavorare su altre cose.

link

Sono tornato indietro e ho guardato il codice che ho fatto qualche anno fa, e penso che sia orribile. Stiamo imparando costantemente in questo campo e il modo migliore per codificare correttamente è guardare gli esempi di altre persone e imparare da loro. Una volta che impari qualcosa di nuovo, condividilo con gli altri in modo che tutti noi possiamo trarne beneficio.