Come scrivere meno codice [chiuso]

Una qualità che vorrei sviluppare è scrivere codice più conciso. Con una scrittura più concisa, almeno secondo me, l'opportunità di aggiungere bug al codice è più piccola. È più facile leggere il codice per altri.

La mia domanda è se si tratta di qualcosa che viene solo con l'esperienza o è qualcosa che puoi fare esplicitamente per sviluppare quella qualità?

Direi che nel complesso è qualcosa che arriva con il tempo e l'esperienza, ma potresti scoprire che se fai un po 'di lavoro con lingue più concise, riporti quella qualità nelle tue normali lingue di lavoro.

Certamente dopo un anno o due di lavoro con Ruby ho scoperto che il mio C # è diventato molto più tonico. Penso che se dovessi capire meglio la programmazione funzionale (un'ambizione in corso), probabilmente ne trarrebbe di più.

Inoltre ci sono alcune linee guida che possono aiutare, ad esempio se scrivi le stesse due righe più di una volta per dividerle nel loro metodo. Questa è una semplice linea guida, ma riduce rapidamente le righe di codice e taglia e incolla la programmazione, di cui la maggior parte di noi è colpevole di volta in volta.

Se capisci l'eredità, puoi spesso risparmiare ripetendo lo stesso codice in luoghi diversi, fornendo funzionalità comuni alle classi principali. Questo è ovvio in linea di principio, ma qualcosa che alla gente spesso manca nella pratica.

Ci può essere una differenza tra scrivere meno codice e avere meno codice nella tua applicazione- a volte puoi usare la generazione di codice per evitare di doverti ripetere, quindi scrivi solo poche righe di codice, ma quelle generano un sacco di altro codice per te - questo può darti molta influenza. Guarda cosa fa uno strumento come Rails o Entity Framework per capire quanto possa essere utile. Sii chiaro sulla necessità e pensaci due volte, tre volte e poi quattro volte a far rotolare la tua generazione di codice, che può portarti all'inferno di YAGNI.

Comprendi la tua lingua, la tua API e i tuoi strumenti. Ancora una volta questo sembra ovvio, ma nel corso degli anni ho scritto così tanto codice che in seguito mi sono reso conto che stava riproducendo funzionalità che avrei potuto ereditare dall'API o utilizzare una funzione del linguaggio per semplificare che sono arrivato a capire che poche ore di lettura su la documentazione per l'API con cui sto lavorando mi farà risparmiare molte ore di programmazione o debug in seguito. Allo stesso modo, la maggior parte delle piattaforme con cui lavori hanno una grana: impara a lavorare come si aspettano e la tua vita sarà molto più semplice. Dedica un po 'di tempo a trovare la direzione della resistenza minima per la piattaforma con cui stai lavorando e otterrai risultati molto migliori.

Se ti stai chiedendo se esiste un modo migliore per fare qualcosa, probabilmente c'è e vale sempre la pena scoprire come fare le cose meglio.

Un ottimo modo per scrivere meno codice è cercare di evitare di reinventare la ruota e utilizzare i componenti software esistenti quando disponibili.

Una risposta comune che ottengo quando chiedo perché le persone hanno fatto il proprio ORM, il proprio motore di registrazione, i propri componenti dell'interfaccia utente o il proprio tutto:

Ma il nostro è meglio

Credo che questa affermazione sia corretta nella maggior parte dei casi, ma l'impatto negativo sul ROI è molto elevato nella maggior parte dei casi. Mamma, fai i piatti migliori, vero? Ma non puoi chiedere a tua mamma di tornare a casa e prepararli tutti i giorni.

Ecco perché penso che gli sviluppatori debbano interessarsi all'impatto finanziario delle loro scelte. Alcuni di loro sono:

• Lavoro extra richiesto per costruire il componente
• Lavoro extra per i nuovi arrivati ​​per impararlo
• Enorme lavoro extra per mantenerlo

Mi piace pensare che quei fornitori di componenti siano il tuo team esteso che lavora per te per una piccola parte di ciò che avresti pagato per costruirlo, mantenerlo e migliorarlo da solo.

È meglio per l'intera azienda massimizzare il ROI piuttosto che lavorare per massimizzare la soddisfazione del nostro ego;) Maggiore è il guadagno della tua azienda, maggiori sono le probabilità che le tue condizioni di lavoro e il tuo stipendio aumentino.

Secondo me, scrivere meno codice può essere fatto in diversi modi:

• Non ne avrai bisogno . Non codificare qualcosa che non ti serve ancora. Il codice indica solo i requisiti. In questo modo, ridurremo il codice necessario per scrivere.

• Non ripetere te stesso . Credo che usare CMS, framework o la libreria di terze parti sia un modo per applicare il principio DRY.

• Astrazione . E, ultimo ma non meno importante, la programmazione dell'astrazione può ridurre molto anche il codice. Astrattando il codice, la possibilità di riutilizzarlo aumenterà perché riduce la duplicità.

Al di là della comprensione di un linguaggio di programmazione, penso che la comprensione di un problema da parte degli altri e trovare una buona soluzione abbia molto a che fare con questo. Esistono molte soluzioni alla maggior parte dei problemi, non tutte sono ottimali. Puoi guidare dalla città A alla città B attraverso strade diverse: una potrebbe impiegare due ore, l'altra potrebbe raddoppiare. È la stessa idea in programmazione. Potresti conoscere una lingua molto bene, ma potresti trovare una soluzione che prende, diciamo, due pagine di codice, mentre qualcun altro scoprirà una soluzione che può essere implementata in un quarto della metà della dimensione del codice. L'ho visto molto nel corso degli anni.

Assicurati di avere una buona comprensione del problema. Analizzalo, trova una o più soluzioni, valuta i pro e i contro (ovviamente le "soluzioni con una" s "varieranno notevolmente da un problema all'altro, in generale qui). Poi c'è l'implementazione della soluzione scelta, che è qui che entra in gioco la tua comprensione della lingua (e del framework, se applicabile).

Si può dire che l'intera arte della programmazione dipende proprio da questo.

Puoi studiare lingue che hanno un'enfasi tradizionale sulla chiarezza e sulla concisione (ad es. Haskell, Scheme, Python) o persino paradigmi terser come Factor e altri linguaggi concatenativi, ma alla fine, tutto ciò che potresti scegliere di studiare dovrebbe in definitiva contribuire ad aiutarti a scrivere più breve , codice meno ridondante.

Come tutte le altre afflizioni, se non ammetti di avere un problema, non cercherai una soluzione. L'esperienza inizia ad essere un fattore quando hai appreso come appare meno codice. Quando rivisiti il ​​tuo codice, è il momento giusto per determinare se puoi riutilizzare il codice o eseguire il refactoring su un codice inferiore. Microsoft è stata in grado di migliorare la velocità di stampa con Windows 2000 NON eseguendo lo spooling due volte (citazione del dipendente Microsoft in una delle loro demo gratuite).

1. Torna indietro al tuo vecchio codice a lungo,
2. mettilo sotto controllo di versione,
3. scrivere alcuni test per avere una ragionevole speranza di non introdurre nuovi bug,
4. riscrivere.

Ripeti ad libitum. E benvenuto all'inferno.

Lo sviluppo test-driven potrebbe aiutare. Usando questo, scrivi solo il codice minimo richiesto per superare quel test.