Stile di codifica (fai di più, poi semplifica) [duplicato]

Sembra una buona abitudine per me. La prima regola nella codifica è di farlo funzionare. Dopo averlo fatto, ripulisci il codice e rendilo pulito, comprensibile e semplice se puoi.

Tuttavia, se passi molto tempo a progettare la tua soluzione e perdi un sacco di tempo a creare cose che non hanno bisogno di esistere, è probabilmente una cattiva abitudine - come se stessi creando un sacco di classi e solo andando un po 'fuori controllo. Ma finché stai lavorando per "farlo funzionare", allora non sembra che sia un problema.

La mia risposta potrebbe essere poco fuori tema, ma questo metodo funziona per me.

Prima ancora di iniziare a programmare devi pensare: che tipo di strutture ho bisogno per risolvere un problema e che tipo di algoritmi.

Spesso troverai che la soluzione esiste già e che devi solo implementarla nel tuo progetto *. Non provare mai a reinventare una ruota: se hai bisogno di qualcosa, c'è sempre una possibilità significativa che qualcuno lo abbia già fatto meglio.

Dopo averlo fatto, rimani solo con incollare quelle parti (algoritmi e strutture) insieme e questo è solitamente più semplice di pensare a un problema nel suo insieme.

* Ecco perché l'istruzione è così importante nell'IT. Più algoritmi e tipi di strutture conosci più spesso, durante la programmazione ti sorprenderai a pensare: "Oh, lo so, devo usare questo . Oh, e qui ho bisogno di usare che ".

Questa abitudine è tipica per TDD. Prima implementalo e poi refactoring. Penso che ogni sviluppatore non implementa il modo migliore al suo primo tentativo. Finché hai dei test unitari per verificare che tutto funzioni ancora dopo il refactoring, non c'è problema.

Trovo che quando lavoro sulla carta ciò che voglio fare prima del tempo, faccio un codice meno inutile. A volte finisco con diverse bozze su carta, quindi è ancora un processo iterativo, ma le iterazioni tendono ad essere più veloci, dal momento che non devi arrivare fino al codice di lavoro per rendersi conto che qualcosa che pensavi fosse una buona idea vinta lavorare dopotutto (Non deve nemmeno essere dettagliato come lo pseudo-codice, un semplice disegno può essere molto utile. Inoltre, non c'è nulla di magico sulla carta, anche le lavagne funzionano bene.)

Pulire il codice è una buona abitudine, ma in questo modo si punta al codice pulito in primo luogo. Avrai ancora bisogno di ripulire le cose anche se pianifichi in anticipo, ma non avresti abbastanza confusione per iniziare.

Scrivere e riscrivere il codice non è un problema, né scrivere più codice di quanto sia assolutamente necessario. Ogni volta che scrivi del codice e lo butti via o lo rifatti, stai imparando - in effetti è probabilmente il modo migliore per imparare. Cercare di essere "Ottimale" sul tipo di codifica o sul tempo di digitazione è davvero dannoso per tutti i soggetti coinvolti.

Inoltre, tutte quelle variabili "Extra" sono spesso una buona idea: se ti aiutano a capire il tuo codice inizialmente, è meglio lasciarlo lì dentro! Non cadere nella trappola di scrivere il codice di pensiero minimale che è il modo per renderlo leggibile, il codice Terse non equivale a leggibile.

Ti sto suggerendo di non diventare troppo entusiasta di "Rimozione" del tuo codice. Se è assolutamente inutile, certo, ma creare funzioni extra e più variabili tende ad essere una cosa abbastanza buona, se le rimuovi dopo aver compreso la soluzione, stai solo facendo del male a tutti quelli che guardano il codice dopo di te (incluso te stesso qualche mese in seguito).

È comunque importante mantenere il tuo codice DRY, in effetti è quello che considero il singolo principio più importante in tutto lo sviluppo del software, ma una volta che il tuo codice è ASCIUTTO, riducendo ulteriormente la verbosità da ciò che ti ha aiutato a comprenderlo e progettarlo di solito è dannoso.

I migliori programmatori e codificatori medi di solito hanno un codice simile, la differenza è il tempo necessario per farlo. Se ti prendi il tempo per pianificare in anticipo e risolvere il problema prima di iniziare a programmare ti aiuterà a diventare uno dei migliori programmatori. Ovviamente non sarai in grado di prevedere ogni problema, quindi dovrai far funzionare le piccole cose e questo può diventare piuttosto disordinato, quindi quello che stai facendo è chiamato refactoring del codice (e questa è una buona pratica). La cosa migliore da fare è prima risolvere l'algoritmo su carta e capire come si compirà il compito. Quindi codificalo e fallo funzionare, quindi rifattore per pulire, rendere più leggibile e ottimizzare. Guarda quanto tempo ti ci vuole per risolvere / code / debug e di questi tre il debug dovrebbe impiegare meno tempo, quindi programmare un po 'di più e risolvere il problema più a lungo. Spero che questo aiuti.

Niente di sbagliato con questa habbit secondo me. Più a lungo si codifica, migliori saranno le abilità di codifica e di risoluzione dei problemi, quindi tutto il codice "extra" otterrà di meno.

Ho lavorato come ingegnere software junior per circa due anni e uso ancora questo tipo di approccio, con la differenza che, col passare del tempo, sono stato più spesso proiettato verso il basso soluzione / algoritmo.

Le variabili di test sono ancora una cosa comune per me, ma vengono utilizzate in modo molto più efficiente.

Quindi non preoccuparti, assicurati di mantenerlo il più pulito possibile e di utilizzare molti commenti e regioni.

Prova a contrassegnare il tuo codice estraneo, se possibile. I controlli variabili possono essere scritti come asserzioni per esempio che aggiungono informazioni semantiche al tuo codice, I.e. queste proprietà devono essere soddisfatte ecc. Poiché le asserzioni di solito vengono abbandonate in "modalità di rilascio" (a seconda della lingua / piattaforma) molte asserzioni non devono essere rimosse ma possono fungere da ulteriore aiuto per il debug quando si cambiano parti del programma.

Analogamente per le variabili temporanee che usi per il debug del codice, dai un nome a un prefisso debug_ o qualcosa di simile, in modo che tu possa dire subito il loro scopo. La programmazione è un processo iterativo, quindi quello che fai è perfettamente normale.

Una cosa da notare: le asserzioni possono essere persino migliori dei commenti nella spiegazione del codice. Usali (saggiamente)!

La verbosità è molto comune per i programmatori junior, ma tu sei più avanzato del fatto che tu conosca quella verbosità e tenti di rimuoverla.

All'inizio potrebbe sembrarti una buona abitudine che tu sia sempre un refactoring, ma se hai bisogno di un sacco di refactoring dopo la prima volta significa che dovresti migliorare le tue prestazioni di codifica iniziale.

Refactoring più spesso è la chiave. Non aspettare che la tua implementazione sia completata prima del refactoring. Se la tua funzione è troppo lunga, crea una nuova funzione. Se il tuo codice è ripetitivo, creane una funzione. Pensa di rifattorizzare tutto il tempo in cui esegui il codice, non solo dopo aver terminato la codifica.

Il costante refactoring ti aiuterà quando dovrai rivedere ciò che hai scritto ed è più facile eseguire il debug. È normale che il tuo codice non funzioni correttamente dopo la prima volta e anche te stesso in pochi giorni dopo potresti aver dimenticato la tua logica se il tuo codice sembra un disastro.

Credo che avere problemi a "prevedere ciò che è necessario" sia naturale vista la tua breve esperienza: stai solo iniziando a imparare come scrivere programmi. Ci vuole un sacco di prove ed errori per imparare a progettare e questa è l'abilità necessaria per evitare la codifica estranea. Sembra che tu sia sulla strada giusta.

Forse scrivi già commenti dettagliati ma in caso contrario potresti provare a utilizzare i commenti come strumento di progettazione su piccola scala. Prova prima a scrivere le descrizioni. Prima di scrivere una singola riga di codice in un metodo, scrivici una descrizione: cosa fa, quali parametri prende e cosa restituisce, quali effetti collaterali ha e che tipo di eccezioni potrebbe generare. Si potrebbe anche delineare l'implementazione usando i commenti prima di scrivere il codice. Lo stesso vale per le classi o i moduli: prova a descriverli nel loro insieme prima di immergerti nei dettagli e nell'implementazione.

Questo approccio ti costringe a progettare qualcosa prima della codifica. Potrebbe anche portarti a pensare prima alla struttura, che sarà essenziale in fondo alla strada.

La solita sequenza è "rendi corretta, quindi rendila elegante, quindi rendila efficiente". Il primo passaggio potrebbe comportare un codice lungo quanto necessario, purché tu possa tenere traccia di ciò che sta accadendo.

La graduale affinazione del codice è un processo in corso, e anche i migliori programmatori sono noti per dire che alcuni dei loro i giorni più produttivi sono stati quando hanno rimosso 1000 righe di codice . Dovresti preoccuparti quando non puoi semplificare ulteriormente il tuo codice grande e complesso, non il contrario.

L'approccio "Fai di più, poi semplifica" ha uno svantaggio importante: i metodi grandi e complessi sono molto difficili da testare. E vuoi un test che documenti che il tuo codice refactored produca gli stessi risultati.

Quindi hai davvero bisogno di iniziare a pensare alla separazione delle preoccupazioni il prima possibile, altrimenti passerai molto tempo a lottare con test unitari davvero difficili, che potrebbero essere prevenuti. Hai bisogno di piccoli pezzi di codice fin dall'inizio. Per me, la comprensione del "Single Responsibility Principle" (SRP) è stata molto importante in questo contesto. Inoltre, l'iniezione di decenza ha un ruolo molto importante qui.

È difficile farlo all'inizio (è ancora per me un sacco di volte), ma man mano che acquisisci esperienza, imparerai lentamente a identificare i modelli nel codice e saprai come suddividere questi schemi in semplici e strutture testabili.