Vedo che la comunità di sviluppo è molto concentrata nel fare le cose nel modo giusto e personalmente vorrei fare lo stesso anch'io, tuttavia, è una buona o una cattiva idea per un novizio focalizzarsi su principi di progettazione, schemi di progettazione, e commentando il codice quando si inizia, o è meglio lasciar correre la creatività e potenzialmente scrivere codice sciatto. Dove dovrebbe disegnare una linea il novizio?
Il perfezionismo è una scusa per uno sviluppatore inadeguato per non aver completato il lavoro.
Larry Wall, nel glossario della prima edizione di Programmazione Perl , note famose:
We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.
Nella seconda edizione del libro i termini sono ulteriormente definiti:
Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. (p.609)
Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608)
Hubris: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607)
Mentre Perl non è la tazza di tè di tutti, le idee espresse nella citazione sopra si applicano alla programmazione in generale. Molto recentemente ho assegnato quello che pensavo fosse un compito facile per uno sviluppatore relativamente nuovo, e gli ho dato linee guida esplicite per saltare alcune "buone pratiche". L'attività era sensibile alle prestazioni, un processo in background che avrebbe ricevuto un enorme ammasso di XML da un webservice (che non abbiamo controllato), trasformato i dati, fare un paio di semplici verifiche e quindi memorizzarli nel nostro database. La dimensione dei dati XML era enorme e ci aspettavamo che diventasse gigantesca in un futuro molto prossimo, questa cosa doveva essere veloce. Davvero veloce.
Ciò che ha inventato, una settimana dopo, può essere descritto solo come un pezzo di merda eccessivamente ingegnerizzato (valutazione onesta). Ha funzionato, in modo impeccabile, per alcuni piccoli file XML che gli ho dato per testare le trasformazioni dei dati, ma quando sono stato collegato al servizio web effettivo che non riusciva a far fronte, le cose hanno iniziato a bloccarsi in modo casuale, come fanno di solito quando lo sfondo processo affronta problemi di prestazioni. Quando ho rivisto il suo codice ho scoperto, con mio orrore, che mi aveva completamente ignorato, il codice era pieno di ... modelli di design! Poor noob ha splendidamente descritto un esempio quasi accademico del modello di strategia per quello che era essenzialmente un istruzione switch , tra le altre cose.
Ora, non fraintendetemi, applicare i modelli non è stata la causa principale dei problemi di prestazioni che abbiamo dovuto affrontare, tuttavia ha trascorso tutta la settimana a cercare di scrivere il codice "migliore" possibile quando avrebbe dovuto rapidamente hackerare il codice in un giorno o due, e poi passare il resto del tempo a testare la dannata cosa e identificare i colli di bottiglia. E ora ho dovuto scavare migliaia di righe di codice non necessarie per iniziare a farmi un'idea di cosa stesse succedendo. Nessuna possibilità di sprecare il mio tempo in quel modo, ho appena demolito tutto e l'ho scritto da zero in poche ore.
Ho discusso il suo codice con lui e le mie conclusioni sono:
L'entusiasmo è grande, affrettarsi ad applicare concetti che potresti non comprendere ancora pienamente nel tuo codice. Anche se li comprendi pienamente, molto spesso non ne hai realmente bisogno. Uno dei principi guida di Programmazione estrema è "Non ne avrai bisogno" (YAGNI ), ed è un principio che cerco sempre di passare ai nuovi sviluppatori. Ron Jeffries, uno dei fondatori di XP, spiega :
Often you will be building some class and you’ll hear yourself saying "We’re going to need...".
Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them. Here’s why:
- Your thoughts have gone off track. You’re thinking about what the class might be, rather than what it must be. You were on a mission when you started building that class. Keep on that mission rather than let yourself be distracted for even a moment.
- Your time is precious. Hone your sense of progress to focus on the real task, not just on banging out code.
- You might not need it after all. If that happens, the time you spend implementing the method will be wasted; the time everyone else spends reading it will be wasted; the space it takes up will be wasted.
- You find that you need a getter for some instance variable. Fine, write it. Don’t write the setter because "we’re going to need it". Don’t write getters for other instance variables because "we’re going to need them".
The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code.
You’re not gonna need it!
Molte delle mie risposte sui programmatori sostengono le migliori pratiche, tuttavia spero di non aver indotto in errore nessuno a pensare che l'applicazione di queste migliori pratiche sia un obiettivo in sé. L'obiettivo è quello di fare le cose, done è meglio che perfetto . Non seguire ciecamente i dogmi, senza una profonda comprensione dei concetti e delle pratiche, e un prurito per grattare ti stai solo preparando per un mondo di guai.
Ulteriori letture:
Scrivi un prototipo come preferisci. Se funziona, va bene, lascia perdere. Se vuoi mostrare il codice a chiunque altro - pensa a cosa può essere fatto meglio e refactoring.
Dopo un po 'di tempo scriverai il codice nel modo giusto senza nemmeno accorgertene. Ovviamente "la strada giusta" dipende dalle politiche dell'azienda, dal codice di condotta comune, dalle normative, ecc.
Se provi ad essere perfetto dall'inizio, procederai molto lentamente. Ti farai domande come:
Ci vuole tempo (linee di codice) per diventare abile in qualsiasi disciplina. Per essere abili nella programmazione devi risolvere i problemi. Scrivere 100 applicazioni CRUD ti insegnerà meno di alcune diverse applicazioni complesse.
Non dimenticare che fare le cose in tempo è più importante che fare le cose correttamente ma tardi, o non realizzarle affatto, ma avere tutto il codice perfettamente lucido ma incompiuto.
Migliorare costantemente la qualità del codice che scrivi è semplicemente un dato. Devi farlo.
Ma mantienile nel contesto: impari e applichi nuove cose per ottenere un ritorno sull'investimento, che può essere crudo produttività, affidabilità, futura manutenibilità o QUALSIASI altro criterio che ritieni abbia un peso.
Quando sento la parola perfezionista, generalmente penso a qualcuno la cui motivazione principale è essere perfetta, non produttiva. Non essere quella persona Vuoi che l'utilità aumenti la tua produzione. Lascia che i tuoi sforzi siano guidati da un guadagno tangibile e realistico. Non farti intrappolare nella trappola del "tutto vale la pena imparare".
Sono ancora un principiante, ma darò i miei 2 centesimi:
Sono il tipo di programmatore che è perfezionista. A volte faccio fatica a trovare giorni per trovare una risposta elegante, ea volte non la trovo nemmeno. Ma è perché l'apprendimento di quel tipo di cose è il mio obiettivo. Se è anche il tuo, potresti considerare di essere un po 'perfezionista (ma vedi sotto).
Se la tua attenzione sta completando qualcosa e poi non la usi mai più, non cercare di essere fantasiosa. Scrivere codice di fantasia ti aiuterà se hai bisogno di usare di nuovo quel codice. Se non lo fai, fallo funzionare.
Ora, alcuni suggerimenti che posso darti:
-Se si scrive la stessa funzionalità un sacco di volte, considerare di refactoring tale funzionalità in una libreria ben strutturata, per uso personale. In questo modo puoi imparare come mantenere qualcosa e non dovrai mai più riscriverlo di nuovo.
-Si pragmatici per il tuo obiettivo. Vuoi imparare? Bene, scrivi codice di fantasia. Vuoi spedire e mantenere? Trova un midterm.
-Avere un focus alla volta. Non cercare di imparare, spedire e insegnare, ad esempio, allo stesso tempo. Si può fare solo una cosa alla volta.
-Se hai il tempo, leggi molto. A volte questo ti aiuta ad avere un'idea di qualche problema particolare.
Spero di aver contribuito a qualcosa:)
Se avessimo creato un modello fuori da questo problema di apprendimento del codice, questo sarebbe stato influenzato da molte forze, tra cui:
Non vuoi fare qualcosa in modo sbagliato ripetutamente, perché diventerà la tua abitudine per il futuro. Tuttavia, vuoi fare qualcosa e se il perfezionismo ti lascia paralizzato, potresti voler rischiare qualche errore.
Ci sono probabilmente alcuni parallelismi con il modo in cui ai bambini viene insegnato a scrivere in questi giorni. Sono incoraggiati a scrivere, ignorando l'ortografia ma mettendo grande enfasi sul lasciare fluire la loro creatività. Mi fa rabbrividire quando vedo questo tipo di lavoro sulle bacheche delle scuole elementari, ma penso che il metodo abbia un merito se c'è un passo successivo (probabilmente lo stesso giorno o almeno una settimana), dove con un dizionario o un consiglio di un insegnante, cercano l'ortografia e forse eseguono una regola come i dopo e tranne dopo C, quindi hanno un modo per evitare di digitare "ricevuto".
Poiché la programmazione è così complessa, i nuovi programmatori hanno difficoltà a mantenere tutte le regole per la programmazione nella loro testa allo stesso tempo. Non c'è molto da fare al riguardo tranne forse strumenti migliori e tutorial migliori. Una formazione bilanciata e di qualità è un'impresa complessa. Proprio come qualcuno che fa allenamento con i pesi o altri tipi di allenamento sportivo non penserebbe all'allenamento per la forza di una parte del corpo da solo o all'allenamento per forza solo senza un po 'di flessibilità, velocità, resistenza o equilibrio.
La tua formazione dovrebbe includere programmi brevi, programmi medi, programmi lunghi, programmi in cui ripeti il programma di qualcun altro (apprendimento cinematico), qualcosa in cui inizi con del codice e lo cambi per fare qualcosa di nuovo, o un programma in cui crei il codice da un problema di parole (questo accade molto nell'insegnamento della matematica). Qualcosa in cui vedi le cose rappresentate come testo e come figure, qualcosa che si concentra su alcune affermazioni, qualcosa con un ampio mix di tipi di istruzione. Dovresti vedere qualcosa che fa tutto il lavoro direttamente e qualcosa che fa quasi tutto il lavoro attraverso le API.
Il perfezionismo è il nemico di tutti, per definizione. È (secondo Wikipedia)
a personality disposition characterized by an individual striving for flawlessness and setting excessively high performance standards
Quasi tutte le decisioni che prendi sono un compromesso.
Se i tuoi standard sono troppo alti in un'area, probabilmente stai trascurando un altro.
Se scrivi una parte di codice veloce, leggibile, flessibile, facile da gestire, ben documentata e ben testata, ma ti porta 3 volte più a lungo di quanto dovrebbe basarsi sull'importanza dell'attività, non è così perfetto, vero?
Pensa a questo: le correzioni / linee di codice temporanee durano spesso più del previsto se non per sempre ...
La cosa più importante è davvero grok i principi fondamentali del design come KISS, DRY, SRP, LSP. Devi avere la capacità di vedere dove sono state violate queste regole e perché è importante. Una volta riconosciute le "violazioni delle regole", è possibile scrivere codice sciatto in determinate situazioni (ad esempio, eliminare il codice per le migrazioni), perché in questo modo si conoscono le insidie e come pulire il caos quando è necessario.
Leggi altre domande sui tag design programming-practices learning