Share
Abbiamo tutti le nostre cattive abitudini. In questo articolo, esamineremo un elenco di cattive pratiche che vale la pena esaminare, rivalutare e correggere immediatamente.
Tutorial ripubblicatoOgni poche settimane, rivisitiamo alcuni dei post preferiti del nostro lettore da tutta la cronologia del sito. Questo tutorial è stato pubblicato per la prima volta nel febbraio del 2011.
Ogni volta che apro un progetto che non è mio, è accompagnato da un pizzico di paura che sto camminando in una specie di scenario di Temple of Doom, pieno di trappole, codici segreti e quella riga di codice che, al alterazione, abbassa l'intera app (e probabilmente manda un gigantesco masso che mi sfreccia verso uno stretto corridoio).
Quando abbiamo torto, e tutto va bene a parte alcune piccole differenze in "come avrei fatto", tiriamo un sospiro di sollievo, rimboccandoci le maniche e tuffandoci nel progetto.
Ma quando abbiamo ragione ... Beh, questa è una storia completamente diversa.
Il nostro primo pensiero nel vedere questo disastro immondo è di solito sulla falsariga di "Chi diavolo pensa che sia?" E giustamente così; che tipo di programmatore creerebbe volentieri un tale disastro da un progetto?
Il codice terribile è l'accumulo di più piccole scorciatoie o concessioni.
Il tuo primo istinto potrebbe essere supporre che il ragazzo che ha costruito il progetto sia un novizio, o forse è solo un idiota. Ma non è sempre così.
La mia teoria è che quel terribile codice è l'accumulo di più piccole scorciatoie o concessioni - tanto spesso quanto è il prodotto dell'inesperienza o della stupidità. Ciò rende l'applicazione Temple of Doom molto più spaventosa, perché chiunque l'abbia costruita potrebbe essere altrettanto intelligente, esperta e ben informata di te. Sono semplicemente diventati pigri o hanno messo insieme le cose in fretta, e ognuna di quelle piccole scorciatoie ha aggiunto l'incubo tortuoso che ti è appena caduto in grembo.
Anche più spaventoso, questo potrebbe significare che ad un certo punto qualcuno ha ereditato il tuo codice e scoppiò immediatamente in lacrime.
Non fa mai male riesaminare le tue attuali pratiche e assicurarti di non prendere scorciatoie che potrebbero contribuire al sonno perduto di qualcun altro.
Dedichiamo alcuni minuti e passiamo ad alcune scorciatoie, concessioni e altre cattive pratiche comuni per garantire che i nostri progetti non stiano spaventando la paura nei cuori degli abitanti del villaggio.
Prima di scrivere una singola riga di codice, dovresti avere un solido piano di attacco.
Prima di scrivere una singola riga di codice, dovresti avere un solido piano di attacco. Questo ti aiuta a rimanere in pista ed evita il codice errante che ti confonderà più tardi, per non parlare di un'altra povera anima.
Un approccio che mi ha permesso di risparmiare tempo, sia nello sviluppo che nei commenti, è di scrivere prima una bozza nei commenti:
Come puoi vedere, senza scrivere una singola riga di codice, so già esattamente come sarà il file. La cosa migliore è che puoi pianificare un'intera applicazione in questo modo, e se arrivi a un punto in cui una funzione richiede un tweak della funzionalità a un'altra, tutto quello che devi fare è cambiare il commento.
Richiede un cambiamento nel modo in cui ti avvicini allo sviluppo, ma renderà le tue capacità di organizzazione del progetto andare oltre il tetto.
NOTA: Alcuni di questi commenti non sono necessari; alcuni di loro cambieranno; altri dovranno essere aggiunti - è previsto. Questo è un po 'come scrivere un profilo per un foglio o scrivere una lista della spesa: ti tiene semplicemente sulla strada giusta quando vai a finire il lavoro.
Non commento nulla
Tuttavia, il singolo peggior problema con la maggior parte del codice che ho riscontrato è che è mal commentato o non commentato affatto.
Mi rattrista dover scrivere questo. Quando qualcosa è facile come commentare, non dovrebbe essere qualcosa che dobbiamo ricordarci a vicenda.
Tuttavia, il singolo peggior problema con la maggior parte del codice che ho riscontrato è che è mal commentato o non commentato affatto. Questo non solo aggiunge un bel po 'di tempo alla mia iniziale familiarizzazione con il progetto, ma garantisce quasi che una correzione fatta usando un metodo non convenzionale per necessità mi confonderà. Quindi, se finisco di fare qualsiasi refactoring, interromperò inavvertitamente l'app perché non ho riscontrato le circostanze attenuanti che hanno richiesto la correzione.
Questo processo può richiedere da 10 minuti a 6 ore. (E tu mi hai fatto questo, so dove vivi, vengo per te.)
Quindi dillo a voce alta:
io, [Dichiara il tuo nome], con la presente giuriamo di fare commenti in qualsiasi situazione in cui lo scopo del codice che ho scritto non è immediatamente evidente.
"Immediatamente apparente" si riferisce al codice che non può essere auto-documentante (perché non sarebbe ragionevole farlo) e / o non completa un compito semplice. Pensaci in questo modo: se dovessi fermarti a pensare alla tua soluzione per più di qualche secondo, probabilmente meriterebbe una rapida spiegazione.
Per illustrare il mio punto, userò un esempio tratto da un articolo che ho scritto di recente per i principianti. Considera quanto segue:
$ pieces = explode ('.', $ image_name); $ extension = array_pop ($ pezzi);Cosa fa? Hai dovuto fermarti a pensarci? Ancora non sai per certo cosa è archiviato $ estensione?
Guarda di nuovo questo frammento, ma con un breve commento:
// Scarica l'estensione dal nome file $ pieces = explode ('.', $ Image_name); $ extension = array_pop ($ pezzi);Cinque secondi alla volta si sommano in grande stile.
Ora, dare un'occhiata a questo codice non richiede alcuna potenza cerebrale aggiuntiva: vedi il commento, vedi il codice e non devi mai mettere in discussione il suo intento.
Potrebbe farti risparmiare solo cinque secondi di contemplazione, ma se hai un'app complessa, cinque secondi alla volta si sommano in grande.
Quindi smetti di inventare scuse. Scrivi il dannato commento.
Sacrificio Chiarezza per brevità
Buoni esempi di sacrificare la chiarezza per brevità includono nomi di variabili poco chiare e l'eliminazione delle parentesi graffe.
È una tentazione universale ottenere qualcosa nel minor numero possibile di caratteri, ma quella tentazione è un po 'come la tentazione di avere solo un paio di mutande: certo, il bucato viene fatto rapidamente, ma i problemi che sorgono dalla vostra scelta enormemente superano i benefici.
Buoni esempi di sacrificare la chiarezza per brevità includono nomi di variabili brevi e non chiari (come
$ un- cosa fa$ unnegozio?) e lasciando cadere le parentesi graffe.Eliminare le parentesi graffe dalle strutture di controllo è un particolare problema mio. Se non ti piacciono le parentesi graffe, passa a Python. In PHP, è troppo facile perdere il significato senza di loro.
Ad esempio, guarda questo insieme di istruzioni ifid nidificate senza parentesi graffe:
5) echo "Maggiore di 5!"; altrimenti echo "Meno di 5!"; altrimenti echo "Maggiore di 10!"; eco "
Un'altra nota. ";A prima vista, sembra che l'ultima riga debba essere attivata solo se il valore di
$ pippoè maggiore di 10. Ma ciò che sta effettivamente accadendo è un caso di indentazione impropria; l'ultima frase di eco scatterà a prescindere da cosa$ pippoI negozi.Riesci a capirlo se lo guardi per qualche secondo e sai che le istruzioni if-else senza parentesi graffe riguardano solo la riga successiva immediata? Ovviamente.
Dovresti sprecare l'energia per capirlo? Assolutamente no.
L'aggiunta di parentesi graffe aggiunge poche righe, ma chiarisce immensamente la frase, anche con la rientranza dispari:
5) echo "Maggiore di 5!"; else echo "Meno di 5!"; else echo "Maggiore di 10!"; eco "
Un'altra nota. ";Sì, è una buona cosa mantenere il tuo codice conciso, ma non a scapito della chiarezza. Vale la pena le linee extra per garantire che nessuno debba sbattere la testa contro una tastiera cercando di setacciare il codice.
Non seguire uno standard di codifica
Scegli uno standard e attenersi ad esso.
Diventare carino con la tua formattazione potrebbe soddisfare i tuoi stimoli artistici, ma non fa bene a nessuno. Scegli uno standard (raccomando lo standard di codifica PEAR) e seguilo. Tutti ti ringrazieranno. (Compreso te stesso, un giorno.)
Fidati di me. Ero quel ragazzo una volta - volevo avere uno "stile firma" - e ho sprecato un sacco di ore a sistemare la mia atroce formattazione in seguito. C'è un tempo per essere diversi e un tempo per farlo come tutti gli altri.
Quando si tratta di programmazione, pensala come una lingua parlata. La grammatica e la punteggiatura esistono per una ragione: quindi possiamo capire chiaramente l'un l'altro quando scriviamo le cose. Pensa agli standard di codifica come una versione geek di Elements of Style di Strunk & White: seguire le linee guida significa che le persone capiscono cosa stai cercando di dire, non che sei una persona noiosa.
Codice duplicato
Lo stai facendo male.
Prova a guardare ogni singolo pezzo della tua app come qualcosa che dovrà cambiare a un certo punto. Se lo fa, dovrai aggiornare più di un file? Se hai risposto si, è tempo di rivalutare il modo in cui scrivi il codice.
Se hai codice che fa la stessa cosa in più di un posto nella tua app, stai sbagliando.
Non segui un modello di sviluppo
Dovresti sempre avere una struttura quando esegui il codice.
Dovresti sempre avere una struttura quando esegui il codice. Non intendo dire che devi seguire il pattern MVC o qualcosa di altrettanto rigido, ma intendo dire che dovresti sapere come classificare i componenti e dove dovrebbero andare.
Seguendo uno schema di sviluppo logico, molte decisioni diventano automatiche e qualcuno che entra nel tuo codice non deve indovinare molto quando cerca una determinata funzionalità nella tua base di codice.
Non ci vuole molto tempo, e davvero chiarirà le tue app in grande stile.
Sei troppo intelligente per il tuo bene
La soluzione più semplice è solitamente la più appropriata
C'è una linea sottile tra una soluzione furba e una complicata.
È sempre la tentazione di provare qualche nuovo dolce trucco che hai imparato, ma dobbiamo resistere all'impulso di forzare una soluzione complessa in uno spazio in cui è sufficiente uno semplice.
A livello di base, la soluzione più semplice è solitamente la più appropriata. Stai cercando di ottenere punto A a punto B - prendendo una deviazione punto fantastico è divertente, ma in realtà non aggiunge alcun beneficio.
La tua soluzione super dolce, tuttavia, pone un problema in cui qualcun altro potrebbe non aver visto quella particolare soluzione e si perderebbe. Non è perché non sono intelligenti come te; è probabile perché non hanno visto quel particolare articolo o non stavano cercando di forzare un concetto quadrato in un problema circolare.
Non ti stupire, ma ricorda di evitare di complicare eccessivamente le cose "solo per causa".
Sei un Wang
Evita attivamente di rendere il tuo codice difficile da capire a tutti i costi.
Quando mi sono avvicinato allo sviluppo, ho lavorato con un ragazzo che si era autoproclamato programmatore "esperto". Ogni volta che ho avuto una domanda su un concetto, non mi ha mai dato una risposta diretta; per ottenere la risposta alla mia domanda iniziale, ho dovuto rispondere a un paio di domande preliminari per "dimostrare che puoi gestire la risposta".
Questo ragazzo era anche molto bravo a scrivere codice che era criptico, confuso e, in generale, poco chiaro.
File come il suo sono il risultato di programmatori che pensano di dover rendere difficile la lettura del loro codice per "tenere fuori gli idioti".
La filosofia generale alla base di questo tende ad essere, "Se non sei abbastanza intelligente da capire questo codice, non dovresti esserlo in primo luogo."
Questo è un approccio alla programmazione profondamente sbagliato e antisociale. È un modo molto elitario di guardare le cose, e mostra che il programmatore ha perso il contatto con le sue radici da principiante, quando lui stesso aveva bisogno di aiuto.
Evita attivamente di rendere il tuo codice difficile da capire a tutti i costi. Non ti rende più fresco o più intelligente, e non rafforza il rispetto. Ti rende solo un wang.
Amico, di cosa stai parlando??
Se smetti di imparare, i progetti su cui lavori sono bloccati in qualsiasi periodo di tempo decidessi di stabilirti.
Oltre alle scorciatoie e alla pigrizia generale di cui sopra, un'altra cosa che potrebbe trattenerti è una mancanza di apprendimento continuo e di progressi in avanti.
La tecnologia non sta cambiando perché la comunità in generale è annoiata e abbiamo deciso di ridipingere; la maggior parte delle nuove tecnologie emerge per risolvere in modo più efficiente e semplice i problemi esistenti. Scegliere di ignorare il progresso è scegliere di avviare il lento processo di marginalizzazione del proprio skillset.
Ecco alcune cose che possiamo smettere di fare per assicurarci che i nostri skills siano aggiornati, tutto senza dover rinunciare ai fine settimana.
Stai cercando di farlo tutto da solo
Scopri quali di questi programmatori hanno un approccio simile e lascia che ti riempiano di novità.
Non puoi stare al passo con l'intera comunità. Come chiunque abbia mai provato a tenere il passo con un abbonamento a più di 200 blog tecnologici ti dirà, semplicemente non può essere fatto entro un ragionevole lasso di tempo.
Fortunatamente, ci sono quelli all'interno della comunità che dedicano il loro tempo a guardare la progressione della tecnologia e riportare le loro scoperte. Se ti prendi il tempo per scoprire quale di questi programmatori ha un approccio e uno stile simile, puoi lasciare che ti riempiano di novità.
Guardare i 2-5 di questi blogger di tipo "early adopter" può essere più utile che iscriversi a tutti i blog tecnologici che incontri per diversi motivi:
Tra i blogger PHP di cui mi fido sono David Walsh e Chris Shiflett.
Intendo semplicemente suggerire che ti sentirai più soddisfatto come programmatore e vedrai i tuoi talenti avanzare sempre di più se sceglierai di guardare sempre al prossimo livello di programmazione.
Se non stai facendo qualcosa che ti sfida, qualcosa non va. Trovare nuove sfide all'interno dei progetti è la maggior parte di ciò che rende la programmazione gratificante (O almeno dovrebbe essere).
Prova a porsi le seguenti domande quando inizi a guardare i nuovi progetti:
Tieni presente: non sto parlando di fare qualcosa di grossolanamente complesso, qui.
Può essere semplice come ricordare di aggiungere Docblock ai tuoi oggetti, o complesso come rendere l'app compatibile con XMLRPC, quindi è più facile per gli utenti pubblicare gli aggiornamenti.
Cerca di non stabilirti e convinciti di aver imparato tutto ciò che imparerai. Questo è quando inizierà a diventare brutto per te.
Discuti sempre il tuo codice con i tuoi colleghi programmatori.
Il modo migliore per migliorare è discutere il tuo codice con i tuoi colleghi programmatori. Questo può essere fatto attraverso molteplici strade: se ti senti particolarmente estroverso, scrivi un tutorial o pubblica un progetto open source; se non ti senti all'altezza di qualcosa di simile, forse potresti frequentare un forum della comunità e offrire aiuto ai nuovi arrivati.
"In che modo aiutare i noobs mi aiuta a progredire?" tu chiedi. Di solito, se pubblichi una soluzione che potrebbe essere ottimizzata, altri programmatori esperti saliranno e offriranno dei miglioramenti. Quindi questo approccio è un doppio smalto di suggestione: non stai solo aiutando a far progredire la comunità offrendo le tue conoscenze ai principianti, ma affini le tue abilità apprendendo le tue abilità per farle vedere e aiutarti a sviluppare.
Se vuoi entrare in qualcosa di nuovo e interessante che è un po 'troppo impegnato per essere inserito in un progetto reale, il modo migliore per imparare è iniziare un progetto parallelo che utilizzi detta tecnica.
In questo modo, puoi progredire al tuo ritmo, nel tuo tempo libero e non rischiare mai di perdere una scadenza o di "sbagliare".
Se lo stiamo facendo bene, dovremmo sempre migliorare. E la logica ci dice che se stiamo meglio ora, prima eravamo peggio. E se seguiamo questa linea di ragionamento abbastanza lontano, c'era un punto in cui eravamo terribili.
So che quando ripenso ad alcuni dei codici che ho scritto in passato, sono inorridito.
Non saremo mai perfetti. Ma possiamo fare tutto quanto è in nostro potere per assicurarci di avvicinarci il più possibile.
Quali sono i tuoi animaletti quando si tratta del codice di altri sviluppatori? Fatemi sapere nei commenti!
Accentsconagua