Scrittura di codice pulito senza conoscenza sull'argomento programmato

Naviga le tue risposte
6

Ci sono suggerimenti che possono aiutarmi a creare codice pulito quando sto lavorando con qualcosa di poco documentato e completamente nuovo per me?

È facile scrivere un codice pulito quando scriviamo qualcosa per la seconda volta. Tuttavia, solitamente i problemi che stiamo affrontando sono nuovi per noi.

Diciamo che stiamo lavorando con una libreria scarsamente documentata: abbiamo creato la nostra prima implementazione ben progettata, ma dopo averla compilata sembra che non funzioni. Troviamo alcune soluzioni rapide sul forum e lo incolliamo. Non funziona ancora, quindi stiamo cercando rapidamente un altro frammento di codice da incollare. Qualche tempo dopo che il nostro codice pulito è pieno di soluzioni rapide prese da Internet.

Alla fine, il nostro programma inizia a funzionare. Guardiamo di nuovo il nostro codice e sembra antipatico - una grande procedura piena di soluzioni "temporanee" che abbiamo applicato mentre cercavamo di farlo funzionare. Abbiamo due scelte: riscrivere tutto da zero sperando che il codice refactored funzioni, o lasciarlo così com'è dal momento che sta funzionando. Nella maggior parte delle aziende, viene adottato il secondo approccio, almeno fino a quando non verranno rilasciate altre esercitazioni per la libreria.

A volte non abbiamo la possibilità di eseguire il debug di ogni singola riga che stiamo aggiungendo. Inoltre, quando lavoriamo con la libreria male documentata, di solito dobbiamo indovinare quale parte del codice ha fatto funzionare il nostro programma. Sto riscontrando i maggiori problemi quando fornisco soluzioni ingegneristiche quando il debugging richiede molto tempo, dal momento che è necessario avviare il programma su un dispositivo reale.

    
posta JoshThunar 08.05.2017 - 19:33
fonte

3 risposte

15

Se non sai come funziona una biblioteca, non perdere tempo con il tuo codice di produzione e lancia ipotesi azzardate di frammenti di codice fino a quando il codice sembra funzionare. Questa è una codifica non professionale dei cowboy.

Invece, scrivi test di esplorazione per scoprire come funziona realmente la lib, e quando hai abbastanza confidenza hai capito cosa succede, quindi scrivi il tuo codice di produzione. Ciò ti obbliga a mantenere le tue soluzioni "temporanee" nei test e ti aiuta a mantenere pulito il codice di produzione. Inoltre, prova a dare ai tuoi metodi di prova buoni nomi e qualche descrizione di ciò che stanno testando, quindi i tuoi test diventano la documentazione mancante sotto forma di esempi.

Oltre a ciò, penso che la risposta di @DaveGauer contenga molti buoni consigli. Dovresti provare a sviluppare un atteggiamento di ripulire le cose immediatamente, prima che finiscano il tuo controllo. Separare il tuo "codice sperimentale" dal tuo codice di produzione potrebbe aiutarti con questo.

    
risposta data 08.05.2017 - 23:39
fonte
20

Per prima cosa, stai costantemente riscrivendo mentre procedi. Non aspettare un grande refactoring. Non passare immediatamente al prossimo problema quando ne hai uno capito. Pausa un momento per riflettere su una parte di soluzione di un insieme più grande.

In secondo luogo, considera di non utilizzare l'uso di copia e incolla così tanto. Certamente, usa gli esempi di altre persone. Ma digita tu stesso . Cambia i nomi delle variabili e la struttura del codice in modo che corrisponda allo stile del tuo progetto. Tu vorrà infrangere il codice perché hai dimenticato di rinominare una variabile. ti ti prenderà un po 'di più. Ma capirai cosa hai inserito e si adatta meglio al tuo progetto e avrai un senso di proprietà molto maggiore per il codice.

We've got two choices: rewrite everything from the scratch hoping that refactored code will work, or leave it as it is, since it is working.

Hai una terza scelta. Leggi il nuovo pezzo di codice da cima a fondo come il capitolo di un romanzo che stai scrivendo. Pensa come un editor di fiction. Apporta le modifiche mentre procedi per migliorare la chiarezza e verificare eventuali errori. Le tue funzioni dovrebbero essere sufficientemente piccole da poter essere ragionevolmente rifattorate in una singola seduta e comprenderne l'intera interezza.

Il debito tecnico può essere una cosa terribilmente demoralizzante. Lo so.

Inoltre, nessuno ti darà mai il tempo di fare la cosa giusta . Devi prendere l'iniziativa da solo. Se devi, non permettere a nessuno di sapere che hai risolto il problema fino a quando non ti sei dato il tempo necessario per rendere il codice leggibile e corretto. Questo vale anche per i test.

    
risposta data 08.05.2017 - 20:42
fonte
-3

Ci sono due aspetti che puoi migliorare senza conoscere lo scopo del codice:

  • applica dipendenza dipendenza / inversione di controllo (DI)
  • riduci la duplicazione del codice

Puoi fare uno dei due facendo affidamento sui refactoring automatici del tuo IDE.

Dovresti iniziare con DI e quindi aggiungere UnitTests alla tua applicazione che ti aiuterà a capire le regole di business nel codice e ti impedirà di alterare la logica in modo indesiderato quando riduci la duplicazione del codice.

DI has no value in and of itself; – Frank Hilema

Ha tanto "valore dentro e fuori di sé" come qualsiasi altro principio OO che seguiamo. Che non puoi vedere il suo "valore" non significa che non ce ne sia uno.

it is only useful when you need it. – Frank Hilema

DI / IoC migliora notevolmente (ri) l'usabilità.

E uno dei casi più importanti in cui questo "riutilizzo" è necessario è unit test .

L'applicazione di DI / IoC riduce la complessità dei test di unità perché abilita la sostituzione delle dipendenze con test double .

Anche per applicare DI / IoC puoi seguire un algoritmo formale. L'unica cosa che devi sapere è quale delle invocazioni dell'operatore nuovo istanzia una dipendenza piuttosto che un Oggetto Valore / DTO .

Poiché il problema dei PO è che lei non sa nulla di ciò che vuole "ripulire", questo sarebbe il mio approccio preferito:

  • Applica DI / IoC
  • scrivi test di unità per verificare / capire cosa fa il codice.
  • applica altri rifattori come metodo di estrazione , rinomina identificatori , estrai classe e altri salvataggi tramite i test di unità scritti nel passaggio precedente.
risposta data 08.05.2017 - 20:37
fonte

Leggi altre domande sui tag

Come posso sapere quando un argomento del programma dovrebbe essere una variabile di configurazione? Chiarificazione della definizione del programmatore principale [chiuso]