Robert Martin, Czysty kod. Recenzja książki „Kod kung fu” dla programistów

Witajcie Javarashewici! Artykuł ten jest recenzją książki „Czysty kod” Roberta Martina. Razem zastanowimy się nad sposobami ulepszenia i optymalizacji Twojego kodu, a na koniec czeka Cię małe, ale ciekawe zadanie. Każdego dnia, gdy otwieramy edytor kodu, mamy do czynienia z wieloma klasami, funkcjami i zmiennymi. Najlepszą opcją jest, jeśli jest to Twój kod napisany od zera, napisany raz, jest w nim kilka linijek, pracujesz nad nim sam, nie ma żadnych edycji i dalszego wsparcia ze strony klienta. ALE! Jak pokazuje praktyka, tak, myślę, że sam rozumiesz, że tak się nie dzieje. Zasadniczo będziemy musieli w jakiś sposób wchodzić w interakcję z członkami naszego zespołu, utrzymywać „hinduski” kod i analizować produkty na miliony linii. Często słyszałem takie odpowiedzi od moich kolegów trenerów: „Ten kod został napisany przeze mnie i nie zamierzam go nikomu pokazywać”, ale kiedy widzę prośby o Pomoc z takim kodem, zajmuje to bardzo dużo czasu czas (czasami naprawdę dużo czasu), aby zagłębić się i zrozumieć. Co ta osoba chciała mi powiedzieć, mam ochotę nawet powiedzieć „wymaż i napisz jeszcze raz”! Doceniaj czas i energię ludzi, którzy chcą Ci pomóc, pisz poprawnie, a jeśli nie wiesz jak, nigdy nie jest za późno na naukę. Książka Roberta Martina wyróżnia się spośród książek tego formatu tym, że zawiera wiele przykładów w Javie. Może to być trochę fanatyczne stwierdzenie z mojej strony, ale zostało napisane w stylu OOP, a mianowicie poprzez pisanie części i sekcji. Książka jest łatwa do zrozumienia i czytania, dzięki czemu łatwo ją czytać w drodze lub wieczorem przed snem. Czysty Kod jest podzielony na 3 części. W pierwszej części jesteśmy proszeni o przebrnięcie przez teorię książki, poznanie wzorców projektowych i zasad dobrych manier. Druga część zaprasza nas do ćwiczenia refaktoryzacji i pisania, a trzecia część to końcowe podsumowanie kodu, który „pachnie” przykładami. Cóż, autor poruszył wiele tematów, do których potrzebna będzie głównie znajomość Java Core, ale są też sekcje poświęcone testom jednostkowym JUnit, logowaniu Log4j, znajomości najprostszych wzorców w projektowaniu (ale jak mówiłem powyżej, nie ma jest ich wiele, a wszystko co niezrozumiałe da się z powodzeniem wygooglować, tak i przeanalizować to w kursie JavaRush). Wszystkie rozdziały książki nie są ze sobą powiązane, możesz z powodzeniem rozpocząć lekturę od rozdziału, który Ci się podoba. Krótkie podsumowanie głównych idei, które zaczerpnąłem z książki. Byłbym wdzięczny za uwagi na ich temat, w których możesz podzielić się własną wizją tych wypowiedzi.

1. Komentarze == zło.

W większości przypadków komentarze to kule, którymi staramy się zatuszować nasz zły kod. W niektórych przypadkach kłamią także na temat celu metod lub zmiennych, jeśli występuje ciągła refaktoryzacja kodu.

2. Kod skomentowany, kod martwy.

Pozostawienie tych fragmentów kodu w aplikacji jest równoznaczne ze śmieciami. Niewykorzystany kod gromadzi się z czasem i zakłóca czystość Twojej aplikacji, co jakiś czas sprawdzaj kod pod kątem takich modułów.

3. Nagłówki metod, klas i zmiennych.

Warto poświęcić temu tematowi osobne artykuły. Nie bądź leniwy i napisz nazwy, które mogą powiedzieć o ich przeznaczeniu. Poznaj pewne standardy pisowni tytułów. Ten temat jest „must have” do szczegółowego przestudiowania.

4. Każda metoda i zmienna ma swoje miejsce w hierarchii klas.

Zazwyczaj klasa może mieć zmienne i metody (statyczne i niestatyczne), konstruktor, klasy zagnieżdżone i wewnętrzne oraz wyliczenia. Krótko mówiąc, informacji jest dużo i trzeba określić miejsce każdego z nich w klasie. Jeśli spojrzysz na podstawowe klasy Java, zobaczysz, że struktura jest przejrzysta, możemy zobaczyć każdą część na swoim miejscu, oczywiście w twoich projektach może się to zmieniać w ramach projektu, ale nie w każdej klasie. Dla siebie zdefiniowałem następującą strukturę konstrukcji: Na początku klasy mam zmienne statyczne, następnie zmienne obiektowe + Wyliczenia, jeśli istnieją. Po zmiennych definiuję konstruktory klas. Następnie piszę metody pracy z klasą. Po metodach piszę gettery i settery. I na sam koniec mam zajęcia wewnętrzne. Możesz skorzystać z mojej struktury lub napisać własną w komentarzach.

5. Poziomy abstrakcji metod.

Dla mnie było to odkrycie nr 1. Każda metoda zawiera operatory tylko na jednym poziomie abstrakcji. Nie należy mieszać ze sobą operacji wielopoziomowych.

6. Obsługa błędów.

Wyjątki zaznaczone czy niesprawdzone, które lepiej zastosować w projekcie (co o tym sądzicie?, napiszcie komentarze)? Jestem zwolennikiem sprawdzania, ale książka pomaga spojrzeć na niesprawdzone wyjątki z zewnątrz. Rzeczywiście, niezaznaczony Wyjątek nie zniekształca sygnatury metody, szczególnie biorąc pod uwagę, że wyjątki „przebijają” kilka warstw jednocześnie. Niedogodność najmniejszej zmiany prowadzi do przedefiniowania całego łańcucha metod przed jej złapaniem, co w wielu przypadkach jest niezwykle niewygodne dla programistów.

7. Formatowanie kodu.

Odpowiednio sformatowany kod jest nie tylko przejrzysty, ale także bardzo czytelny. Od razu masz pojęcie o nawiasach i działaniach wewnątrz. Na przykładzie warunków w konstrukcjach if, else nie należy pisać wszystkiego w jednej linii, lepiej przesuwać długie łańcuchy.

8. Negacje w warunku.

Staraj się unikać zaprzeczeń w warunkach, jest to bardziej czynnik psychologiczny, nasz mózg nie postrzega dobrze zaprzeczenia i tak! zanim wyrażenie może nie zostać zauważone. Na przykład zanegowanie if (!condition.isTrue) jest lepszym rozwiązaniem i przepisanie metody, znacznie ułatwi to w ten sposób (condition.isFalse)

9. Funkcje muszą wykonywać jedną operację.

Jeśli Twoja metoda wykonuje wiele operacji, podziel je na metody z jedną operacją. Metody te są bardzo łatwe w obsłudze, łatwe do przetestowania i, jeśli to konieczne, wymienione lub usunięte.

10. Nie powtarzaj się.

Nie powtarzaj kodu DRY (nie powtarzaj się). Jest to jedna z podstawowych zasad, która znacznie skróci Twój kod, pamiętaj o tym. Spróbuj umieścić wszystkie powtarzające się fragmenty kodu w osobnej funkcji. Oczywiście możemy mówić dużo więcej o DRY, KISS (Keep it simple Stupid), SOLID , YAGNI. Terminy te są niezbędne do zrozumienia i projektowania. Warto poświęcić im osobny artykuł, być może napiszę o nich jeszcze raz, gdyż artykuł ten poświęcony jest recenzji książki „Czysty kod”. Zgodnie z obietnicą, małe i łatwe zadanie dla Ciebie. Program na podstawie podanych danych musi wyliczyć Wskaźnik Otyłości. Wpisz w komentarzach liczbę błędów i poprawek w kodzie. P.S. Kod działa i spełnia swoją funkcję, jeśli jest używany prawidłowo.

//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;
    }
}