codice sentimentale [chiuso]

Question

Mi sono imbattuto in un articolo che discute il problema di "ammirazione del codice". Fondamentalmente, l'autore parla di come gli sviluppatori dovrebbero essere più scettici sul codice che scrivono. Come possiamo "ammirare" il nostro codice troppo, attaccarci ad esso, rendendoci più vulnerabili agli errori e ad altri disavanzi che potrebbero trovarci di fronte.

Come ti senti riguardo a questo problema? E hai altri suggerimenti su come evitare / essere più consapevoli di questo problema?

Answer 1

Alcuni anni fa, stavo lavorando con un altro su un piccolo "hobby" progetto, e ho capito che dovevamo rivalutare le cose. Avevamo scritto un sacco di codice ma non era tutto un buon codice.

Non volevamo davvero " buttare via " tutto il lavoro che avevamo svolto. Ma ho realizzato qualcosa: ciò che contava di più era la quantità di lavoro che avremmo dovuto mettere d'ora in poi .

Non potevamo cambiare il fatto che avevamo già messo così tanto lavoro nel progetto, quindi l'unico modo per ridurre al minimo la quantità totale di lavoro del progetto sarebbe di minimizzare quantità di lavoro che non avevamo ancora svolto .

Da quel giorno, ho smesso di essere allegato al mio codice. Se sono sicuro che buttarlo via e ricominciare da zero significa meno lavoro che tenerlo e adattarlo alle mie esigenze, allora lo butto via.

Answer 2

Il mio insegnante di arte al liceo ci incoraggiava a prendere quelli che consideravamo i nostri migliori disegni e strapparli; lo chiamò "pulizia dell'anima". Il suo ragionamento era che, come artisti, eravamo spinti a creare opere d'arte e ogni volta che producevamo qualcosa che ci piaceva e che ci dava soddisfazione, la nostra motivazione per continuare a creare sarebbe diminuita.

Quindi ho seguito il suo consiglio e strappato le mie cose migliori, e ha funzionato. Invece di passare il tempo ad ammirare il mio vecchio lavoro, ho creato nuove cose e continuamente migliorato. Ho provato a seguire lo stesso principio con il mio codice, ma in realtà non funziona: il mio computer ha un guscio di plastica resistente che è quasi impossibile da strappare.

Answer 3

Pubblico un frammento dal blog di Jeff Atwood, Succhiare di meno ogni anno e sono d'accordo al 100%.

  

Ho spesso pensato che succhiare di meno   ogni anno è come umili programmatori   Migliorare. Dovresti essere insoddisfatto di   codice che hai scritto un anno fa. Se tu   non lo sono, questo significa che A) tu   non ho imparato nulla da un anno, B)   il tuo codice non può essere migliorato, o C) tu   mai rivisitare il vecchio codice. Tutti questi   sono il bacio della morte per il software   gli sviluppatori.

Answer 4

Ci piace sicuramente ammirare il nostro bel codice, ma non è sempre facile sapere cosa ammirare. Il codice complicato ed elaborato viene talvolta scambiato per codice ammirevole, mentre l'eleganza e la semplicità dovrebbero piuttosto essere le ragioni per cui lottare.

Mi vengono in mente due citazioni:

  

" Il debug è due volte più difficile della scrittura   il codice in primo luogo.   Pertanto, se si scrive il codice come   intelligentemente possibile, lo sei, di   definizione, non abbastanza intelligente da eseguire il debug   si & # 8221;.

     

- Brian Kernighan

e

  

" Rendi tutto semplice come   possibile, ma non più semplice. "

     

- Albert Einstein

Answer 5

Jonathan Edwards ha scritto un saggio straordinariamente bello su questo argomento, spinto dal lavoro sul libro di O'Reilly Beautiful Code . Ecco l'ultimo paragrafo, ma vale la pena leggere anche il resto del saggio.

  

Un'altra lezione che ho imparato è diffidare della bellezza . Sembra che l'infatuazione di un design porti inevitabilmente al crepacuore, mentre si intromettono brutte realtà trascurate. L'amore è cieco, ma i computer no. Una relazione a lungo termine - che mantiene un sistema per anni - insegna ad apprezzare più virtù domestiche, come la semplicità e la convenzionalità. La bellezza è una fantasia idealistica: ciò che conta davvero è la qualità della conversazione senza fine tra programmatore e codice, mentre ciascuno impara e si adatta all'altro. La bellezza non è una base sufficiente per un matrimonio felice.

Altre versioni di questa stessa saggezza esistono in altri campi. Samuel Johnson, a proposito della scrittura:

  

Leggi le tue composizioni e ovunque incontri un passaggio che ritieni particolarmente adatto, mettilo in evidenza.

La versione di William Faulkner fu molto più concisa: "Uccidi i tuoi cari".

Mio suocero lavora come montatore di film ed evita studiosamente il set in cui il film viene girato. Quando deve visitare, si protegge gli occhi il più possibile. Questo perché quando decide se includere o meno una scena nel film finale, non vuole essere influenzato dallo sforzo che è stato necessario per girare la scena. Ciò che conta è quanto bene la scena funzioni nel film finale.

Il mio saggio, " La mia evoluzione come programmatore " (a cui collegherei se non fossi un nuovo utente), riguarda in gran parte l'apprendimento dello scetticismo sul codice che avevo scritto: se funziona, se è utile, se è comprensibile (la programmazione di coppia è stata una vera sveglia Qui). È difficile!

Answer 6

Non ammiro mai il mio codice. Ammiro il codice di altre persone che "prendo in prestito" e provo a emularli o a migliorarli e trovo che più ne so, specialmente riguardo alla codifica, più trovo che non lo so. L'unica cosa di valore sarà che i programmatori di pari ammirino il mio codice e lo prendano in prestito.

Answer 7

Penso che abbia un buon punto. È frustrante lavorare con persone che hanno troppo di questo, poiché ostacola davvero il lavoro di squadra e arrivare alla migliore soluzione al problema.

Dato che posso essere un po 'delirante, provo a mettere in atto pratiche che mi terranno radicato nella realtà. Per il codice,

• test unitari : mi tengono maggiormente concentrato su ciò che il codice dovrebbe fare, al contrario di qualsiasi estratto "bellezza".

• proprietà del codice condiviso : qui ci sono due campi: dare alle persone più proprietà del loro codice e sperare che l'orgoglio prenda il sopravvento, oppure dare loro meno e lasciare che la pressione dei pari entri in gioco. Credo che dare alle persone più proprietà può portare a questa ammirazione del codice. Pratichiamo la proprietà del codice condiviso, quindi sono costantemente costretto a vedere qualcuno riscrivere il mio codice perfetto per renderlo migliore (nella loro mente). Mi sono reso rapidamente conto che ammirarlo troppo era una perdita di tempo ed emotivamente difficile.

• programmazione in coppia : lavorare fianco a fianco con qualcuno ti renderà realistico.

• altri feedback : sono tutti loop di feedback, ma ce ne sono altri. Non c'è modo migliore per vedere se qualcosa funziona che guardare qualcuno (provare a) usarlo. Metti il ??tuo lavoro di fronte a quante più persone possibile. Avere revisioni del codice. Leggi codice di altre persone . Esegui gli strumenti analisi del codice statico .

Answer 8

Sono con PurplePilot - non ammiro il mio codice e come tale sono costantemente alla ricerca di modi nuovi, più efficienti (inferno, più facili) di fare la stessa cosa. Mi piace l'Efficace libro c #, ho raccolto un sacco di codice utile da lì che ammiro.

Non esiterei a buttare via il codice e ricominciare, ma non necessariamente da zero, cioè scrivendo del codice per uno scenario specifico e poi buttandolo via, probabilmente avrai una migliore comprensione dello scenario. In altre parole, è un "problema malvagio", oppure hai trovato un altro modo che non funziona alla Edison.

Si pone una domanda più ampia: se il codice non viene gettato via, o almeno rivisitato, lo sviluppo di librerie che stanno diventando stagnanti è una buona cosa?

Answer 9

Non c'è niente di sbagliato nell'ammirare il tuo codice ... questo fa parte del processo di rafforzamento positivo che ti motiverà a scrivere codice migliore e migliore in futuro.

Tuttavia, l'ammirazione fuori posto o abusata può essere un problema. Se il codice non è davvero buono, o ha bug che non sono stati esposti dall'unità o da altri test, o ha bisogno di refactoring / riprogettazione / sostituzione, allora questa ammirevolezza fuori posto è un problema. E usare l'ammirazione come scusa per saltare una parte del processo - come le revisioni del codice o non avere un atteggiamento scettico nei confronti del codice - è un abuso di ammirazione.

Come qualsiasi altra cosa buona, l'ammirazione per il codice può essere mal riposta o abusata - ciò non significa che sia di per sé cattiva. Sarebbe come dire "la religione è una cosa negativa, perché provoca conflitti e guerre tra le persone".

Answer 10

Due parole: revisione del codice.

Raccogli due o più colleghi sviluppatori e invitali a rivedere / criticare / commentare il tuo codice. "twill farà luce (ammettibilmente duro) sul tuo codice.

Answer 11

Forse è meglio avere una prospettiva più sana - non siamo scienziati missilistici e non stiamo curando il cancro - è solo un lavoro.

(Sì, è ragionevole essere orgogliosi di un intero edificio che hai contribuito a costruire se sei un architetto, ma hanno davvero molta autostima racchiusa in un progetto individuale o un armadio al piano 3 hanno progettato da soli?).