Succhiare di meno ogni anno? [chiuso]

Succhiare di meno ogni anno - Jeff Atwood

Mi ero imbattuto in questo articolo perspicace. Citando direttamente dal post

Ho spesso pensato che succhiare di meno ogni anno sia il modo in cui i programmatori umili migliorano. Dovresti essere scontento del codice che hai scritto un anno fa. Se non lo sei, ciò significa che A) non hai imparato nulla in un anno, B) il tuo codice non può essere migliorato, o C) non riesci mai a rivisitare il vecchio codice. Tutti questi sono il bacio della morte per gli sviluppatori di software.

1. Quanto spesso ti succede o no?
2. Quanto tempo prima di notare un effettivo miglioramento nella codifica? mese anno?
3. Hai mai rivisitato il tuo vecchio codice?
4. Quanto spesso ti affligge il tuo vecchio codice? o quanto spesso devi affrontare il tuo debito tecnico.

È sicuramente molto doloroso correggere vecchi bug e codice sporco che potremmo aver fatto per rispettare rapidamente una scadenza e quelle correzioni rapide, in alcuni casi potremmo dover riscrivere la maggior parte dell'applicazione / codice. Nessun argomento al riguardo.

Alcuni degli sviluppatori che ho incontrato hanno sostenuto che erano già nella fase evoluta in cui la loro codifica non ha bisogno di miglioramenti o non può più essere migliorata.

• Questo succede?
• In caso affermativo, quanti anni nel codice su una determinata lingua ci si aspetta che ciò accada?

Relazionato:

Hai mai guardato indietro al tuo vecchio codice e fatto una smorfia di dolore?

Star Wars Moment in Code "Luke! I am your code!" "No! Impossibile! Non può essere!"

  > Sucking Less Every Year ?

No, ma succhiare diverso ogni anno :-)

Dopo le mie prime recensioni molti anni fa ho sofferto per l'assenza di convenzioni sui nomi.

Poi ho sofferto che il mio codice era (non necessario) implementato per essere il più generico possibile, ma che rendeva il codice difficile da comprendere e mantenere.

Poi ho imparato lo sviluppo test-driven, InversionOfControl, che cosa generici net dot dove e molti altri.

conclusione

la sofferenza di vecchi cattivi habbit decrepita ma è stata compensata eccessivamente da nuove sofferenze che ho avuto perché ho imparato di più.

È interessante notare che tutti i programmatori "rockstar" con cui ho mai lavorato erano estremamente umili, desiderosi di imparare e pronti ad ammettere che non sanno tutto. Cavolo, molti erano in realtà completamente autoironici, almeno in momenti spensierati.

Non credo di aver mai incontrato uno sviluppatore che pensa che la loro codifica "non possa essere migliorata", ma qualcosa mi dice che questi ragazzi sarebbero più lontani da Rockstar che puoi ottenere - per dirla in parole povere.

I seguenti punti non sono consigli ma un registro personale:

• usando meno variabili globali
• non usare abbreviazioni per variabili o nomi di funzioni
• scrivere [alcuni] codici di prova
• non giudicare il codice come lento (o veloce) senza benchmark
• scopri come caricare test un'app
• non aggiustarlo, se non è rotto
• usa uno strumento di gestione del codice sorgente (git / hg)
• il refactoring è interessante, non sottovalutare il costo dei test che comporta
• la sicurezza è difficile, quindi fai attenzione al più presto possibile
• patch alcuni bug di progetto open source
• blog qualcosa di nuovo
• l'usabilità potrebbe non essere una richiesta di funzionalità ma è importante

Non ho imparato tutto in un anno, tutto richiede tempo ...

Spesso la gente pensa che un buon codice accada all'improvviso, ma per la maggior parte di noi semplici mortali un buon codice cresce nella nostra base di codice. Voglio dire, è molto difficile scrivere il software perfetto sin dall'inizio poiché i requisiti sono in costante evoluzione e non siamo programmatori perfetti né decisioni così stupide vengono costantemente prese da manager e programmatori. Quindi vedo ogni requisito cambiare una buona opportunità per trasformare un po 'del vecchio codice in un codice migliore (ed essere pagato per esso!) E ripagare un po' di debito tecnico. Come si suol dire: "lasciare un po 'meglio il repository di codice ogni volta che si commette codice". Quindi il tuo sistema si evolverà in un sistema più vicino all'ideale.

Non conosco assolutamente un programmatore che sia orgoglioso del suo software, ma va bene. Than significa che il programmatore ha imparato nel processo.

Inoltre, se leggi il libro "Codice pulito", aumenterai il tuo codice "fattore di succhiare" più volte. : D

In realtà ho entrambi i lati della medaglia per questo.

Da un lato, guardi il vecchio codice e vedi che è pieno di bug e modi complicati di fare cose che sono semplicemente realizzate sfruttando tecniche e funzionalità linguistiche che non conoscevi allora.

D'altra parte, individua una soluzione particolarmente elegante a un problema e non puoi fare a meno di sorridere con la tua intelligenza.

E poi scorri verso il basso un paio di righe e fai una smorfia di orrore per il fatto che hai usato GOTO in C.

Hmm ... Sono spesso abbastanza piacevolmente sorpreso da quanto sia buono il mio vecchio codice.

Se lo facessi oggi, lo scriverei spesso diversamente, ma se dovessi convivere con i limiti del tempo, non sono sicuro che lo farei. Quando puoi contare su una macchina tipica con almeno un paio di concerti di RAM, puoi (e spesso dovresti) scrivere il tuo codice in modo leggermente diverso rispetto a quando un disco rigido di grandi dimensioni era di 100 megabyte.

1. Quanto spesso ti succede o no?

2. Quanto tempo prima di notare un effettivo miglioramento nella codifica? mese anno?

3. Hai mai rivisitato il tuo vecchio codice?

4. Quanto spesso ti affligge il tuo vecchio codice? o quanto spesso devi affrontare il tuo debito tecnico.

1. Ogni volta che imparo qualcosa di nuovo, si spera che sia ogni giorno.

2. Se riesco ad attuare ciò che ho imparato, è immediato da quando lo realizzo.

3. Sì, solo per (1) Nuove funzionalità, (2) Correzioni di bug, (3) Nostalgia, (4) Guarda come ho risolto qualcosa, può essere utile.

4. In relazione a 1., quando imparo a fare qualcosa di meglio, sono consapevole che alcuni vecchi progetti "avrebbero potuto" essere fatti meglio. Li lascio essere. Assicurati solo che il prossimo progetto sia fatto nel modo migliore. Non mi preoccupo a meno che non sia un vero bug.

In un'altra domanda , l'argomento riguardava i modi per valutare la qualità del proprio codice. Uno dei miei suggerimenti è stato quello di rivederlo in pochi anni, quando la tua esperienza è molto più elevata di quando è stato scritto il codice. Una citazione della mia risposta a questa altra domanda è direttamente correlata alla tua domanda:

"nel mio caso, la durata della vita è di un anno: significa che posso modificare il codice che ho scritto sei mesi fa, ma se il codice è stato scritto due anni fa, ha una forte possibilità di essere lanciato, quindi riscritto completamente, dal momento che fa solo schifo troppo ".

Quindi sì, in pratica, ogni pezzo di codice che ho scritto diventa insopportabile dal mio punto di vista in un anno. E non sto parlando di codice usa e getta, ma anche di quello che ho scritto pensando a qualità, manutenibilità e leggibilità. Per il momento, non c'erano eccezioni.

Per rispondere alla tua seconda domanda sulla durata della vita, varia molto. Un pezzo di codice usa e getta ha una durata di zero secondi : fa schifo subito dopo averlo scritto, ma non importa. Alcuni pezzi di codice che ho scritto erano sopportabili dopo due anni , ma avevano bisogno di alcuni cambiamenti estetici: un po 'di refactoring, applicazione delle regole StyleCop, ecc. In media, nel mio caso preciso, la durata della vita varia tra otto mesi e un anno per C # e tra due sei mesi per PHP.

Devo rivisitare il mio vecchio codice? Sì, ovviamente, come tutti gli sviluppatori, a meno che non ti interessi di DRY e reinventare la propria ruota ancora e ancora. Ci sono anche possibilità di rivedere e migliorare il codice molto frequentemente se hai una base di codice comune che usi in molti progetti . Un altro punto è che se lavori su grandi progetti, alcuni potrebbero richiedere anni , quindi dovrai rivisitare il vecchio codice.

Alcuni degli sviluppatori che ho incontrato hanno sostenuto che erano già nella fase evoluta in cui la loro codifica non ha bisogno di miglioramenti o non può più essere migliorata.

Quando una persona dice che è così perfetta da non aver bisogno di imparare nulla, significa che non è nemmeno in grado di capire quanto sia stupida.

Anche se hai vent'anni di esperienza in computer / programmazione, le cose cambiano troppo in fretta, quindi ci sono sempre nuove cose da imparare e nuove tecniche per migliorare il codice. Ad esempio, un codice C # scritto quando non esisteva .NET Framework 3.0 può molto probabilmente essere reso più leggibile e migliore con le nuove cose che abbiamo oggi (compresi Linq, contratti di codice, ecc.) E questo, anche se il vecchio codice è stato scritto dallo sviluppatore più intelligente.

Succede abbastanza regolarmente quando guardo il codice e mi chiedo "Cosa stavo pensando quando ho scritto questo?"

Di solito ci sono sempre miglioramenti poiché a volte mi viene in mente una nuova idea per l'organizzazione del codice, lo styling del codice o qualcos'altro e mentre potrebbe non essere un grande miglioramento, ogni piccola cosa può aiutare che valga la pena fare.

A seconda dell'ambiente di lavoro, potrei vedere il codice da qualche anno fa mentre continuo a lavorare nella stessa base di codice e ho abbastanza familiarità con ciò che c'è dentro ed è qualcosa da gestire.

Il vecchio codice mi affligge quasi sempre come al solito sto cambiando un sistema esistente o sostituendo il sistema. In entrambi i casi, devo conoscere le stranezze del sistema esistente per assicurarmi che siano presenti nel nuovo.

Mentre sono sicuro che ci sono quelli come Jon Skeet che possono solo pensare a un codice perfetto, la maggior parte delle altre persone che afferma che il loro codice non può essere migliorato, lo afferma da un punto di ego che potrebbe non essere attraente. Allo stesso tempo, in termini di ricerca di un grande miglioramento ogni volta che non sarà sempre il caso.

1. Quanto spesso ti succede o no?

Quanto spesso sono insoddisfatto del mio vecchio codice? Quasi sempre. Ci sono rare eccezioni in cui ho un codice di cui sono davvero orgoglioso ... ma, di nuovo, sono rare. Mi è stato detto che il codice che ho scritto un paio di anni fa era buono ... Mi sono arrabbiato e ho pensato "povero povero per aver visto peggio della spazzatura che ho scritto."

2. Quanto tempo prima di notare un effettivo miglioramento nella codifica? mese anno?

Di solito è in più fasi ... Mi immergo davvero in uno stile o in una metodologia (prendo ad esempio interfacce fluide ... dato che è stato l'ultimo stile per cui ho avuto un enorme bagnato) e macello tutto ciò che scrivo per un mese o quattro . Quindi inizia a sembrare migliore.

3. Hai mai rivisitato il tuo vecchio codice?

Non tutte le volte che vorrei. Gran parte del mio vecchio codice è di proprietà di precedenti datori di lavoro. Il codice personale viene imbiancato troppo spesso.

4. Quanto spesso ti affligge il tuo vecchio codice? o quanto spesso devi affrontare il tuo debito tecnico.

Essendo che i precedenti datori di lavoro hanno la maggior parte del mio vecchio codice e io lavo la maggior parte del mio codice personale ... non molto spesso.