Robert Martin, Təmiz Kod. Tərtibatçılar üçün “kunq fu kodu” kitabına baxış

Salam Cavaraşevilər! Bu məqalə Robert Martinin “Təmiz Kod” kitabının icmalıdır. Biz birlikdə kodunuzu təkmilləşdirməyin və optimallaşdırmağın yollarına baxacağıq və sonda sizi kiçik, lakin maraqlı tapşırıq gözləyir. Hər gün kod redaktorunuzu açdığımız zaman bir çox siniflər, funksiyalar və dəyişənlərlə qarşılaşırıq. Ən yaxşı seçim budur ki, bu, sıfırdan yazılmış kodunuzdursa, bir dəfə yazılıbsa, orada bir neçə sətir var, siz tək işləyirsiniz, heç bir redaktə yoxdur və müştəridən əlavə dəstək yoxdur. AMMA! Təcrübə göstərir ki, bəli, düşünürəm ki, özünüz bunun baş vermədiyini başa düşürsünüz. Əsasən, komandamızın üzvləri ilə hansısa şəkildə əlaqə saxlamalı, “Hindu” kodunu saxlamalı və məhsulları milyonlarla sətirdə təhlil etməli olacağıq. Təlim həmkarlarımdan tez-tez belə cavablar eşitmişəm: “Bu kod mənim tərəfimdən yazılmışdır və mən onu heç kimə göstərmək fikrində deyiləm”, lakin belə kodla kömək üçün Yardım sorğularını görəndə çox uzun çəkir. vaxt (bəzən həqiqətən uzun müddətdir) araşdırmaq və anlamaq üçün adam mənə nə demək istəyirdi, hətta “silmək və yenidən yazmaq” demək istəyirəm! Sizə kömək etmək istəyən insanların vaxtını və enerjisini qiymətləndirin, düzgün yazın və necə edəcəyinizi bilmirsinizsə, öyrənmək üçün heç vaxt gec deyil. Robert Martinin kitabı bu formatlı kitablar arasında Java dilində çoxlu nümunələri ehtiva etməsi ilə seçilir. Bu, mənim tərəfimdən bir qədər fanatik ifadə ola bilər, amma OOP üslubunda, yəni hissələrin və bölmələrin yazılışında yazılmışdır. Anlamaq və oxumaq asandır, kitabı yolda və ya axşam yatmazdan əvvəl oxumaq asandır. Təmiz Kod 3 hissəyə bölünür. Birinci hissədə bizdən kitabın nəzəriyyəsini keçmək, dizayn nümunələri və yaxşı davranış qaydaları haqqında məlumat əldə etmək xahiş olunur. İkinci hissə bizi refaktorinq və yazı təcrübəsinə dəvət edir, üçüncü hissə isə misallardakı “qoxular” kodunun yekun xülasəsidir. Yaxşı, müəllif, əsasən Java Core biliklərinə ehtiyacınız olacaq bir çox mövzuya toxundu, lakin JUnit Unit Tests, Log4j Logging, dizaynda ən sadə nümunələr haqqında biliklərə həsr olunmuş bölmələr də var (lakin yuxarıda dediyim kimi, yoxdur. onların bir çoxu və anlaşılmaz hər şeyi uğurla google-da tapmaq olar, bəli və JavaRush kursunda təhlil edin). Kitabın bütün fəsilləri bir-biri ilə əlaqəli deyil, bəyəndiyiniz fəsildən uğurla oxumağa başlaya bilərsiniz. Kitabdan götürdüyüm əsas fikirlərin qısa xülasəsi. Bu ifadələrlə bağlı öz baxışınızı bölüşə biləcəyiniz şərhlərə görə minnətdar olaram.

1. Şərhlər == pis.

Əksər hallarda şərhlər pis kodumuzu ört-basdır etməyə çalışdığımız qoltuqağaqlardır. Və bəzi hallarda, daimi kod refaktorinqi varsa, metodların və ya dəyişənlərin məqsədi haqqında da yalan danışırlar.

2. Şərh edilmiş kod, ölü kod.

Tətbiqinizdə bu kod parçalarını tərk etmək zibilliyə bərabərdir. İstifadə edilməmiş kod zamanla yığılır və tətbiqinizin təmizliyinə mane olur, vaxtaşırı belə modulların kodunu yoxlayın.

3. Metodlar, siniflər və dəyişənlərin başlıqları.

Bu mövzunu müzakirə etmək üçün ayrıca məqalələrə dəyər. Tənbəl olmayın və məqsədlərini izah edə biləcək adlar yazın. Orfoqrafiya başlıqlarında bəzi standartları öyrənin. Bu mövzu ətraflı araşdırma üçün “Olmalı”dır.

4. Sinif iyerarxiyasında hər bir metod və dəyişənin öz yeri var.

Tipik olaraq, bir sinif dəyişənlərə və metodlara (statik və qeyri-statik), konstruktora, iç içə və daxili siniflərə və nömrələrə malik ola bilər. Bir sözlə, çoxlu məlumat var və hər kəsin sinifdəki yerini müəyyən etmək lazımdır. Əgər java core siniflərinə baxsanız görərsiniz ki, struktur aydın şəkildə strukturlaşdırılıb, biz hər bir hissəni öz yerində görə bilirik, təbii ki, layihələrinizdə layihə daxilində dəyişə bilər, lakin hər sinifdə deyil. Mən özüm üçün aşağıdakı konstruksiya strukturunu müəyyən etmişəm: Sinfin əvvəlində məndə statik dəyişənlər, sonra obyekt dəyişənləri + əgər varsa Enums var. Dəyişənlərdən sonra sinif konstruktorlarını təyin edirəm. Sonra siniflə işləmək üsullarını yazıram. Metodlardan sonra getters və setters yazıram. Və ən sonunda daxili dərslərim var. Siz mənim strukturumdan istifadə edə və ya öz şərhinizi yaza bilərsiniz.

5. Metodların abstraksiya səviyyələri.

Mənim üçün bu, 1 nömrəli kəşf idi. Hər bir metod yalnız bir abstraksiya səviyyəsində operatorları ehtiva edir. Çox səviyyəli əməliyyatları bir-birinə qarışdırmamalısınız.

6. Səhvlərin idarə edilməsi.

Yoxlanmış və ya Yoxlanılmamış İstisnalar, hansı layihədə istifadə etmək daha yaxşıdır (sizcə, şərh yazın)? Mən yoxlanılanların tərəfdarıyam, lakin kitab Yoxlanılmamış İstisnalara kənardan baxmağa kömək edir. Həqiqətən, yoxlanılmamış İstisna metodun imzasını pozmur, xüsusən istisnaların bir anda bir neçə təbəqəni “deşdiyini” nəzərə alsaq. Ən kiçik dəyişikliyin əlverişsizliyi onu tutmazdan əvvəl bütün üsullar zəncirinin yenidən müəyyən edilməsinə gətirib çıxarır ki, bu da bir çox hallarda inkişaf üçün son dərəcə əlverişsizdir.

7. Kodun formatlaşdırılması.

Düzgün formatlaşdırılmış kod təkcə aydın deyil, həm də yüksək oxunaqlıdır. Siz dərhal mötərizələr və içəridəki hərəkətlər haqqında bir fikir əldə edirsiniz. if, else konstruksiyalarında şərtlər nümunəsindən istifadə edərək, hər şeyi bir sətirdə yazmamalısınız, uzun zəncirləri daşımaq daha yaxşıdır.

8. Vəziyyətdəki inkarlar.

Şərtlərdə inkardan qaçmağa çalışın, bu daha çox psixoloji faktordur, beynimiz inkarı yaxşı qəbul etmir və bəli! əvvəl ifadəyə diqqət yetirməmək olar. Məsələn, əgər (!condition.isTrue) metodu yenidən yazmaq daha yaxşıdırsa, bu, bunu belə asanlaşdıracaq (condition.isFalse)

9. Funksiyalar bir əməliyyat yerinə yetirməlidir.

Metodunuz bir çox əməliyyatları yerinə yetirirsə, onları tək əməliyyat metodlarına bölün. Bu üsulları dəstəkləmək çox asandır, sınaqdan keçirmək asandır və lazım olduqda dəyişdirilir və ya çıxarılır.

10. Özünüzü təkrarlamayın.

DRY kodunu təkrarlamayın (özünüzü təkrarlamayın). Bu, kodunuzu əhəmiyyətli dərəcədə azaldacaq əsas qaydalardan biridir, onu yadda saxlayın. Bütün təkrarlanan kod hissələrini ayrı bir funksiyaya yerləşdirməyə çalışın. Əlbəttə, biz DRY, KISS(Keep it simple Stupid), SOLID , YAGNI haqqında daha çox danışa bilərik. Bu terminlər başa düşmək və dizayn üçün vacibdir. Onlar ayrıca bir məqaləyə dəyər, bəlkə də onlar haqqında yenidən yazacağam, çünki bu məqalə "Təmiz Kodeks" kitabının nəzərdən keçirilməsinə həsr edilmişdir. Söz verdiyiniz kimi, sizin üçün kiçik və asan bir iş. Proqram verilmiş məlumatlar əsasında Obezite İndeksini hesablamalıdır. Koddakı səhvlərin və düzəlişlərin sayını şərhlərdə yazın. P.S. Kod işləyir və düzgün istifadə edildikdə öz funksiyasını yerinə yetirir.

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