Robert Martin, Codice pulito. Recensione del libro sul “codice kung fu” per sviluppatori

Ciao Javarasheviti! Questo articolo è una recensione del libro “Clean Code” di Robert Martin. Insieme esamineremo i modi per migliorare e ottimizzare il tuo codice e alla fine ti aspetta un compito piccolo ma interessante. Ogni giorno, quando apriamo il tuo editor di codice, ci troviamo di fronte a tantissime classi, funzioni e variabili. L'opzione migliore è se questo è il tuo codice scritto da zero, scritto una volta, con poche righe, ci stai lavorando da solo, non ci sono modifiche e nessun ulteriore supporto da parte del cliente. MA! Come dimostra la pratica, sì, penso che tu stesso capisca che ciò non accade. Fondamentalmente, dovremo in qualche modo interagire con i membri del nostro team, mantenere il codice "indù" e analizzare i prodotti in milioni di righe. Ho spesso sentito risposte come questa dai miei colleghi di formazione: "Questo codice è stato scritto da me e non lo mostrerò a nessuno", ma quando vedo richieste di aiuto su tale codice su Help, ci vuole molto tempo tempo (a volte davvero tanto tempo) per approfondire e capire cosa voleva dirmi quella persona, vorrei addirittura dire “cancella e riscrivi di nuovo”! Apprezza il tempo e l'energia delle persone che vogliono aiutarti, scrivi correttamente e, se non sai come fare, non è mai troppo tardi per imparare. Il libro di Robert Martin si distingue tra i libri di questo formato in quanto contiene molti esempi in Java. Questa potrebbe essere un'affermazione un po' fanatica da parte mia, ma è stata scritta in stile OOP, cioè nella scrittura di parti e sezioni. Facile da capire e leggere, il libro è facile da leggere mentre sei in movimento o la sera prima di andare a letto. Clean Code è diviso in 3 parti. Nella prima parte ci viene chiesto di ripercorrere la parte teorica del libro, conoscere i design pattern e le regole di buona educazione. La seconda parte ci invita a esercitarci nel refactoring e nella scrittura, e la terza parte è il riassunto finale del codice che “annusa” negli esempi. Ebbene, l'autore ha toccato tanti argomenti per i quali servirà principalmente la conoscenza di Java Core, ma ci sono anche sezioni dedicate ai JUnit Unit Test, al Log4j Logging, alla conoscenza dei pattern più semplici nel design (ma come ho detto sopra, non ci sono molti di loro, e tutto ciò che è incomprensibile può essere cercato con successo su Google, sì e analizzandolo nel corso JavaRush). Tutti i capitoli del libro non sono correlati tra loro; puoi iniziare a leggere con successo dal capitolo che ti piace. Un breve riassunto delle idee principali che ho raccolto dal libro. Sarei grato per i tuoi commenti su di essi, in cui puoi condividere la tua visione di queste affermazioni.

1. Commenti == malvagio.

Nella maggior parte dei casi, i commenti sono stampelle con cui cerchiamo di nascondere il nostro codice errato. E in alcuni casi, mentono anche sullo scopo dei metodi o delle variabili se c'è un costante refactoring del codice.

2. Codice commentato, codice morto.

Lasciare questi pezzi di codice nella tua applicazione equivale a spazzatura. Il codice inutilizzato si accumula nel tempo e interferisce con la pulizia dell'applicazione, controlla di tanto in tanto il codice di tali moduli.

3. Intestazioni di metodi, classi e variabili.

Vale la pena articoli separati per discutere questo argomento. Non essere pigro e scrivi nomi che possano raccontare il loro scopo. Impara alcuni standard nell'ortografia dei titoli. Questo argomento è "must have" per uno studio dettagliato.

4. Ogni metodo e variabile ha il suo posto nella gerarchia delle classi.

In genere, una classe può avere variabili e metodi (statici e non statici), un costruttore, classi nidificate e interne ed enumerazioni. In breve, le informazioni sono molte ed è necessario determinare il posto di ognuno nella classe. Se guardi le classi core Java, vedrai che la struttura è chiaramente strutturata, possiamo vedere ogni parte al suo posto, ovviamente nei tuoi progetti può cambiare all'interno del progetto, ma non in ogni classe. Per quanto mi riguarda, ho definito la seguente struttura di costruzione: all'inizio della classe ho variabili statiche, quindi variabili oggetto + Enum se esistono. Dopo le variabili, definisco i costruttori di classi. Quindi scrivo metodi per lavorare con la classe. Dopo i metodi scrivo getter e setter. E alla fine ho classi interiori. Puoi usare la mia struttura o scriverne una tua nei commenti.

5. Livelli di astrazione dei metodi.

Per me questa è stata la scoperta n. 1. Ogni metodo contiene operatori a un solo livello di astrazione. Non dovresti mescolare insieme operazioni multilivello.

6. Gestione degli errori.

Eccezioni selezionate o non selezionate, quale è meglio utilizzare nel progetto (cosa ne pensi?, scrivi commenti)? Sono un sostenitore del controllo, ma il libro aiuta a guardare le eccezioni non controllate dall'esterno. In effetti, l'eccezione deselezionata non sfigura la firma del metodo, soprattutto considerando che le eccezioni “perforano” più livelli contemporaneamente. L'inconveniente del più piccolo cambiamento porta alla ridefinizione dell'intera catena di metodi prima di rilevarlo, il che in molti casi è estremamente scomodo per lo sviluppo.

7. Formattazione del codice.

Il codice formattato correttamente non è solo chiaro, ma anche altamente leggibile. Ti fai subito un'idea delle parentesi e delle azioni all'interno. Usando l'esempio delle condizioni nei costrutti if, else, non dovresti scrivere tutto in una riga, è meglio spostare lunghe catene.

8. Negazioni nella condizione.

Cerca di evitare la negazione nelle condizioni, questo è più un fattore psicologico, il nostro cervello non percepisce bene la negazione, e sì! prima che l'espressione possa non essere notata. Ad esempio, negando se (!condition.isTrue) è meglio riscrivere il metodo, sarà molto più semplice in questo modo (condition.isFalse)

9. Le funzioni devono eseguire un'operazione.

Se il tuo metodo esegue molte operazioni, dividile in metodi a operazione singola. Questi metodi sono molto facili da supportare, facili da testare e, se necessario, sostituiti o rimossi.

10. Non ripeterti.

Non ripetere il codice DRY (Non ripeterti). Questa è una delle regole fondamentali che ridurrà notevolmente il tuo codice, tienilo a mente. Prova a inserire tutti i pezzi di codice ripetuti in una funzione separata. Naturalmente, possiamo parlare molto di più di DRY, KISS(Keep it simple Stupid), SOLID , YAGNI. Questi termini sono essenziali per la comprensione e la progettazione. Meritano un articolo a parte, forse ne scriverò ancora, visto che questo articolo è dedicato a una recensione del libro “Clean Code”. Come promesso, un compito piccolo e facile per te. Il programma deve calcolare l'indice di obesità in base ai dati forniti. Scrivi nei commenti il ​​numero di errori e correzioni nel codice. PS Il codice è funzionante e svolge la sua funzione se utilizzato correttamente.

//Weight in kg.
//Height in metres.
public class sample {
    public static void main (String[] args) {
        humanIMB humanIMB = new humanIMB(80,1.52);
        System.out.println(humanIMB.Result());
    }
}
class humanIMB {
    public double W; //Weight Human
    public double H; // Height Human
    private static double imb;
    public humanIMB(double w, double h) {
        W = w;
        H = h;
        imb = W / (H * H);
    }
    public double takeW() {
        return W;
    }
    public void putW(double w) {
        W = w;
        imb = W / (H * H);
    }
    public double takeH() {
        return H;
    }
    public void putH(double h) {
        H = h;
        imb = W / (H * H);
    }
    public static double takeImt() {
        return imb;
    }
    public static String Result() {
        String  string = null;
        if (imb >=18.5 & imb <25) {
            string ="Норма, ты в форме!";
        }
        if (imb >=25 & imb <30) {
            string ="Предожирение. Эй, поосторожнее с пирожными ";
        }
        if (imb >=30) {
            string ="Ожирение. SCHWEINE! Хватит жрать, иди на треню!";
        }
        if (imb <18.5) {
            string ="Дефицит массы тела. В модели решил переквалифицироваться?";
        }
        return string;
    }
}