C'è un problema nel modo in cui codifico. Indipendentemente dalla quantità di un piano che scrivo in anticipo, il codice diventa rapidamente complicato.
Leggere libri sulle buone pratiche e tentare di aderire ai loro principi non funziona.
Esiste un modo sicuro per verificare il codice per semplificarlo, oltre ad essere più completo e dedicato nella fase di pianificazione?
Esistono infatti tecniche per semplificare gradualmente il codice e migliorare il design in questo modo. La tecnica generale è conosciuta come "refactoring". Si noti che questo termine è usato sia informalmente (per indicare "qualsiasi cosa che modifica il modo in cui il codice è progettato senza cambiare ciò che fa") e formalmente (per indicare "seguendo una specifica disciplina di refactoring"). Mi riferisco a quest'ultima definizione qui.
In particolare, questo problema è stato molto studiato da Martin Fowler e dal suo libro " Refactoring: Migliorare la progettazione del codice esistente "è uno dei classici libri di ingegneria del software, e vale la pena leggerlo in quest'area.
La tecnica generale suggerita dal libro è:
1) Scrivi test molto dettagliati per la sezione di codice che intendi rifattorizzare.
2) Apporta una piccola modifica specifica al codice. Ad esempio, inline un metodo, rinomina una classe, estrai un codice in un nuovo metodo, estrai una superclasse da una classe esistente, ecc. (Fowler ha elenchi dettagliati di molte piccole trasformazioni nel suo libro, insieme a suggerimenti su come / quando La maggior parte dei nomi delle funzionalità esistenti di "refactoring automatico" come quelle di Eclipse, IntelliJ, ecc. sono state prese da quelle usate nel suo libro. Essenzialmente, sono come "schemi di progettazione" ma sono usati per modificare il codice esistente piuttosto che per progettarlo in primo luogo.)
3) Riesegui i test, per verificare che non hai ancora rotto nulla.
4) Ripeti finché non sei soddisfatto dei risultati.
Quindi, è possibile apportare grandi modifiche al codice accumulando più piccole modifiche, con test tra ciascuna modifica.
Ovviamente, se hai l'abitudine di scrivere e conservare test dettagliati per il tuo codice in primo luogo (una suite di test unitario, una suite di test di regressione, ecc.), il processo sopra descritto sarà molto più facile che se tu debba scrivere i test immediatamente prima di iniziare il refactoring. Inoltre, sarà molto più facile farlo se la parte della tua suite di test che stai rieseguendo tra ogni modifica è in grado di funzionare abbastanza rapidamente.
Nota che il codice di refactoring in questo modo è una DISCIPLINE. Non è la stessa cosa che circola casualmente cambiando codice. Il frequente test durante il processo è essenziale per garantire che eventuali modifiche involontarie apportate al comportamento del programma vengano rilevate rapidamente, mentre è ancora possibile ricordare ciò che hai fatto. Per questo motivo, spesso è anche una buona idea eseguire il refactoring separatamente da altri sviluppi che aggiungono o modificano il comportamento del programma, poiché tali tipi di modifiche potrebbero invalidare i test esistenti. Potresti, ad esempio, alternare fasi: aggiungere una funzione, quindi rifattorizzare un bit, quindi aggiungere un'altra funzionalità, quindi rifattorizzare un po 'di più, quindi correggere un bug, quindi refactoring, ecc.
Se sei coerente nella programmazione usando queste tecniche per semplificare il tuo codice, la tendenza generale del tuo codice nel tempo sarà che diventerà via via più semplice e più facile da leggere, piuttosto che al contrario (che è, purtroppo, più comune in industria).
Potresti anche scoprire che alcune delle comunità attorno alle metodologie di sviluppo del software Agile e / o XP possono essere utili su come / quando / che cosa da rifattorizzare, poiché il refactoring continuo in questo modo è considerato una caratteristica necessaria di molte di queste metodologie .
Ho visto molti progetti diventare gradualmente così croccanti e complicati che nessuno li ha capiti e alla fine dovettero essere scartati, perché il loro mantenimento alla fine richiedeva più sforzi di quanto avrebbero fatto la riscrittura. Il refactoring è un modo per evitare questo problema.
Practice.
No, davvero.
Non apprezzerai mai completamente una tecnica in un libro o in un post sul blog finché non avrai scritto il tuo primo piatto di spaghetti o una grande palla di fango e ti renderai conto che molte di queste tecniche sono solo modi efficaci per domare quella complessità. Poi li capirai a un livello più profondo, molto più profondo di quello del cargoista che sta semplicemente mettendo insieme i modelli per sembrare cool, ma non ne comprende appieno le ragioni.
Guarda i modelli. Qualcuno di loro è facile? Beh, sono decisamente più facili di scrivere un piatto di spaghetti o una grande palla di fango, e doverlo mantenere in seguito. Ma devi ancora studiare questi modelli. Anche il miglior pittore usa più di un pennello.
Il mio unico modo sicuro è:
Not being afraid to refactor the plan at the first hint that the code is turning complex.
(Che, naturalmente, non nega affatto ciò che hai già detto di essere più completo e dedicato nella fase di pianificazione.)
Invia il tuo codice a Revisione codice e lascia che qualcun altro lo semplifichi per te. ☺
Seriamente, se studi le semplificazioni raccomandate tra le migliaia di risposte di Code Review, scoprirai che la gamma di tecniche è troppo ampia per essere riassunta in una risposta. Appena in cima alla mia testa, mi viene in mente:
itertools e list comprehensions.) Fondamentalmente, come dice @RobertHarvey, Practice. Ma ora ti ho dato una risorsa in cui puoi sfruttare l'esperienza degli altri programmatori.
Il modo più semplice è procurarti un mentore che scrive codice pulito, mostragli il tuo codice incasinato e chiedi cosa c'è che non va.
La cosa da capire è che il codice pulito non si verifica in fase di pianificazione e non è possibile "aderire" continuamente ai principi di codifica puliti. Puoi reimpostare periodicamente solo su di loro. scriverà codice disordinato. Non appena lo riconosci, lo aggiusti. Quanto più frequentemente resetti il tuo codice, tanto meglio sarà.
Hai detto di aver letto libri sui principi, quindi sai cosa sono. Puoi essere metodico nel reimpostarli. Spesso è utile prendere un principio agli estremi prima di ritirarsi. Come accordare uno strumento, è più facile sentire il set point corretto se si passa prima. Se la tua funzione è troppo lunga, dividila nel più piccolo pezzo possibile, allora ricombina un po ', forse.
.... no. Non c'è.
Non ho mai pensato prima all'idea di una cosa del genere esistente perché è relativamente ovvio che non esiste una soluzione perfetta, ma ora che ne parli ... sarebbe fantastico !
Tuttavia no, non esiste e non ci sarà mai una soluzione perfetta per garantire che il tuo codice non sia terribile, rapidamente, lentamente o trapposto (in modo sleale?).
Se possibile, utilizzare un IDE fornito con (almeno) questi due componenti:
I libri sono fantastici per capire perché e come - hai bisogno di uno strumento che scoraggi senza pietà il cosa e quanto .
Puoi quindi controllare periodicamente il codice che hai scritto e ovunque, ad es. la complessità ciclomatica di una funzione supera una soglia predeterminata, si rifatta la funzione. E così via. Metti da parte un po 'di tempo in ogni ciclo di sviluppo e dedicalo al refactoring; questo è un possibile "quando". Con il tempo e la pratica sarete in grado sia di stimare meglio il sovraccarico di refactoring, sia di ridurre il sovraccarico, fissando le cose più quasi automaticamente mentre procedete. Inoltre, sarai in grado di vedere quali metriche (e i loro valori) funzionano meglio per te.
(Infine, "overhead" è un'etichetta sbagliata - pensala come "piccoli e comodi versamenti che consentono al tuo codice non di entrare in un enorme debito tecnico, e mandare in bancarotta il progetto a un certo punto in futuro ").
Nella mia esperienza, se uno sviluppatore di software non capisce correttamente il sistema / dominio per cui sta scrivendo il codice, allora il codice rischia di diventare troppo complicato.
La ragione di ciò è abbastanza ovvia. Il codice semplice ha una struttura che rispecchia il problema da risolvere o il dominio che viene modellato. In questo modo il comportamento del codice tende ad emergere dalla struttura, piuttosto che essere codificato come un numero elevato di casi espliciti.
Un altro modo per individuare questo errore è quando hai bisogno di un gran numero di casi di test per verificare che il codice funzioni correttamente e scopri errori in tutti i tipi di casi limite. Se il software fosse stato progettato bene, non ci sarebbero molti casi limite.
Quindi lavora sodo per cercare di capire il dominio del problema o il sistema che stai modellando. Non accettare solo una specifica o una serie di requisiti da qualcun altro e codice per quello. Abbattere le barriere tra gli esperti di dominio e gli ingegneri del software; diventa tu stesso un esperto di dominio.
Leggi altre domande sui tag refactoring programming-practices