Succhiando di meno ogni anno? [chiuso]

  > Sucking Less Every Year ?

No ma Succhiare diversi Ogni anno : -)

Dopo le mie prime recensioni molti anni fa ho sofferto di mancate convenzioni sui nomi.

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

Poi ho imparato lo sviluppo testdriven, InversionOfControl, quali generici di net dot dove e molti altri.

conclusione

la sofferenza delle vecchie haabit decrepite è stata compensata dalle nuove sofferenze che ho ricevuto perché ho imparato di più.

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

Non penso di aver mai incontrato uno sviluppatore che pensa che il loro codice "non possa essere migliorato", ma qualcosa mi dice che questi ragazzi sarebbero più lontani dalla rockstar che puoi ottenere - per usare un eufemismo.

I seguenti punti non sono consigli ma un registro personale:

• utilizzando un numero minore di variabili globali
• non utilizzare l'abbreviazione di variabili o nomi di funzioni
• scrivi [alcuni] codici di test
• non giudicare il codice come lento (o veloce) senza benchmarking
• scopri come caricare test un'app
• non aggiustarlo, se non è rotto
• usa uno strumento di gestione del codice sorgente (git / hg)
• il refactoring è bello, non sottovalutare il costo del test che porta
• la sicurezza è difficile, quindi fai attenzione prima possibile
• corregge 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 le persone pensano che un buon codice si verifichi all'improvviso, ma per la maggior parte di noi comuni mortali il buon codice cresce nella nostra base di codice. Voglio dire, è molto difficile scrivere il software perfetto fin dall'inizio, poiché i requisiti cambiano continuamente e non siamo programmatori perfetti, né le decisioni così stupide vengono prese costantemente da manager e programmatori. Poi vedo che ogni requisito cambia una buona opportunità per rifattorizzare parte del vecchio codice in codice migliore (e pagarlo!) E ripagare un po 'di debito tecnico. Come si suol dire: "lasciare il repository del codice un po 'meglio ogni volta che si commette il codice". Quindi il tuo sistema si evolverà in un sistema più vicino all'ideale.

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

Inoltre, se leggi il libro "Clean Code", aumenterai il tuo codice "suck factor" più volte. : D

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

Da un lato, si guarda al vecchio codice e si vede che è pieno di bug e modi complicati di fare cose che sono semplicemente compiuti sfruttando le tecniche e le funzionalità linguistiche di cui non si conosceva allora.

D'altra parte, individua una soluzione particolarmente elegante a un problema e non puoi fare a meno di rilasciare un ghigno compiaciuto su quanto sei stato furbo.

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

Hmm ... Spesso sono abbastanza piacevolmente sorpreso da quanto è buono il mio vecchio codice.

Se lo facessi oggi, lo scriverei in modo diverso, ma se dovessi vivere con i limiti del tempo, non sono sicuro che lo farei. Quando puoi contare su una macchina tipica con almeno un paio 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. How often does this happen or not happen to you?

2. How long before you see an actual improvement in your coding ? month, year?

3. Do you ever revisit Your old code?

4. How often does your old code plague you? or how often do you have to deal with your technical debt.

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

2. Se riesco a implementare ciò che ho imparato, è immediato da quando lo implemento.

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 come fare qualcosa di meglio, sono consapevole che alcuni progetti precedenti "potrebbero" essere stati fatti meglio. Lascio che siano. Assicurati che il prossimo progetto sia fatto nel modo migliore. Non mi preoccupo a meno che non sia un vero bug.

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

"in my case, the lifespan is one year: it means that I may modify the code which I wrote six months ago, but if the code was written two years ago, it has a strong chance of being thrown, then rewritten completely, since it just sucks too much."

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 throw-away, ma anche del codice che ho scritto con 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 che gira ha una durata di zero secondi : fa schifo solo dopo averlo scritto, ma non importa. Alcuni pezzi di codice che ho scritto erano sopportabili dopo due anni , ma avevano bisogno di alcune modifiche estetiche: 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.

Rivedo il mio vecchio codice? Sì, certo, come ogni sviluppatore, a meno che non ti importi di ASCIUGARE e reinventare ancora e ancora la tua ruota. 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 progetti enormi, alcuni potrebbero richiedere anni , quindi dovrai rivedere il vecchio codice.

Some of the developers i had come across argued that they were already at the evolved stage where their coding doesn't need improvement or cant get improved anymore.

Quando una persona dice che è così perfetta che non ha 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 velocemente, quindi ci sono sempre nuove cose da imparare e nuove tecniche per migliorare il codice. Ad esempio, un codice C # scritto quando non c'era .NET Framework 3.0 può molto probabilmente essere reso più leggibile e migliore con le nuove cose che abbiamo oggi (inclusi 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 come talvolta una nuova idea per l'organizzazione del codice, lo stile del codice o qualcos'altro verrà da me e mentre potrebbe non essere un grande miglioramento, ogni piccola cosa può aiutare che vale la pena fare.

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

Il vecchio codice mi sta quasi sempre affliggendo perché di solito sto cambiando un sistema esistente o sostituendo il sistema. In entrambi i casi, devo conoscere le stranezze del sistema esistente per assicurarmi che ci siano nel nuovo.

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

1.Che cosa succede spesso o non ti capita?

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

2. Quanto tempo prima si vede un miglioramento effettivo nella codifica? mese, anno?

Di solito è a tappe ... Mi piacciono davvero in uno stile o in una metodologia (prendi interfacce fluenti, ad esempio ... perché quello era l'ultimo stile per cui ne avevo uno enorme) e macellavo tutto ciò che scrivevo per un mese o quattro. Poi inizia a guardare meglio.

3. Hai mai rivisitato il tuo vecchio codice?

Non tutte le volte che mi piacerebbe. La maggior parte del mio vecchio codice è di proprietà di precedenti datori di lavoro. Il codice personale viene lavato troppo spesso.

4.Come spesso il tuo vecchio codice ti affligge? o quanto spesso hai a che fare con il tuo debito tecnico.

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