رابرت مارتین، کد پاک. بررسی کتاب "کد کونگ فو" برای توسعه دهندگان

سلام جوارشویان! این مقاله مروری بر کتاب «کد پاک» نوشته رابرت مارتین است. با هم به دنبال راه هایی برای بهبود و بهینه سازی کد شما خواهیم بود و در پایان کار کوچک اما جالبی در انتظار شماست. هر روز، وقتی ویرایشگر کد شما را باز می کنیم، با کلاس ها، توابع و متغیرهای زیادی مواجه می شویم. بهترین گزینه این است که اگر این کد شما از ابتدا نوشته شده باشد، یک بار نوشته شده باشد، چند خط در آن وجود داشته باشد، شما به تنهایی روی آن کار می کنید، هیچ ویرایشی وجود ندارد و هیچ پشتیبانی دیگری از سوی مشتری وجود ندارد. ولی! همانطور که تمرین نشان می دهد، بله، من فکر می کنم شما خودتان می فهمید که این اتفاق نمی افتد. اساسا، ما باید به نحوی با اعضای تیم خود تعامل داشته باشیم، کد "هندو" را حفظ کنیم و محصولات را به میلیون ها خط تجزیه کنیم. من اغلب چنین پاسخ هایی را از همکاران آموزشی خود شنیده ام: "این کد توسط من نوشته شده است، و من آن را به کسی نشان نمی دهم"، اما وقتی درخواست هایی را در Help for Help با چنین کدی می بینم، خیلی طول می کشد. زمان (بعضی اوقات واقعاً طولانی) برای عمیق شدن و درک آنچه که آن شخص می خواست به من بگوید، حتی می خواهم بگویم "پاک کن و دوباره بنویس"! قدر زمان و انرژی افرادی را بدانید که می خواهند به شما کمک کنند، درست بنویسید، و اگر نمی دانید چگونه، هرگز برای یادگیری دیر نیست. کتاب رابرت مارتین در میان کتاب‌هایی با این قالب از این نظر متمایز است که نمونه‌های زیادی در جاوا دارد. این ممکن است کمی متعصبانه از جانب من باشد، اما به سبک OOP، یعنی در نوشتن قطعات و بخش ها نوشته شده است. خواندن و درک آن آسان است، خواندن کتاب در حال حرکت یا عصر قبل از خواب آسان است. Clean Code به 3 قسمت تقسیم می شود. در قسمت اول از ما خواسته شده است که با مرور تئوری کتاب، با الگوهای طراحی و قوانین خوش اخلاقی آشنا شویم. بخش دوم ما را به تمرین refactoring و نوشتن دعوت می کند و بخش سوم خلاصه نهایی کد "بوی" در مثال ها است. خوب، نویسنده موضوعات بسیاری را لمس کرده است که برای آنها عمدتاً به دانش Java Core نیاز دارید، اما بخش هایی نیز وجود دارد که به تست های واحد JUnit، Log4j Logging، دانش ساده ترین الگوها در طراحی اختصاص داده شده است (اما همانطور که در بالا گفتم، وجود ندارد. بسیاری از آنها، و همه چیز نامفهوم را می توان با موفقیت در گوگل جستجو کرد، بله و آن را در دوره JavaRush تجزیه و تحلیل کرد). همه فصل‌های کتاب به یکدیگر مرتبط نیستند، می‌توانید با موفقیت از فصلی که دوست دارید شروع به خواندن کنید. خلاصه ای از ایده های اصلی که از کتاب برداشت کردم. از نظرات شما در مورد آنها، که در آن می توانید دیدگاه خود را از این اظهارات به اشتراک بگذارید، سپاسگزار خواهم بود.

1. نظرات == شر.

در بیشتر موارد، کامنت ها عصایی هستند که با آن ها سعی می کنیم کد بد خود را بپوشانیم. و در برخی موارد، در صورت وجود refactoring کد ثابت، در مورد هدف متدها یا متغیرها نیز دروغ می گویند.

2. کد نظر داده شده، کد مرده.

گذاشتن این کدها در برنامه شما مساوی است با زباله. کدهای استفاده نشده در طول زمان انباشته می شوند و در تمیزی برنامه شما اختلال ایجاد می کنند، هر از چند گاهی کد این ماژول ها را بررسی کنید.

3. سرفصل های متدها، کلاس ها و متغیرها.

برای بحث در مورد این موضوع ارزش مقالات جداگانه ای را دارد. تنبل نباشید و اسامی بنویسید که بتواند در مورد هدف آنها بگوید. برخی از استانداردها را در عناوین املا بیاموزید. این موضوع برای مطالعه دقیق "باید" است.

4. هر متد و متغیری جایگاه خاص خود را در سلسله مراتب کلاس دارد.

به طور معمول، یک کلاس می تواند متغیرها و متدها (استاتیک و غیر ایستا)، سازنده، کلاس های تودرتو و داخلی و enums داشته باشد. به طور خلاصه، اطلاعات زیادی وجود دارد و باید جایگاه همه در کلاس مشخص شود. اگر به کلاس های هسته جاوا نگاه کنید، می بینید که ساختار به وضوح ساختار یافته است، ما می توانیم هر قسمت را در جای خود ببینیم، البته در پروژه های شما می تواند در داخل پروژه تغییر کند، اما در هر کلاس نه. برای خودم ساختار ساختاری زیر را تعریف کرده‌ام: در ابتدای کلاس، متغیرهای ثابت دارم، سپس متغیرهای شی + در صورت وجود Enums. بعد از متغیرها سازنده کلاس ها را تعریف می کنم. سپس روش های کار با کلاس را می نویسم. بعد از متدها می نویسم getters و setter. و در نهایت من کلاس های داخلی دارم. شما می توانید از ساختار من استفاده کنید یا خود را در نظرات بنویسید.

5. سطوح انتزاع روش ها.

برای من این کشف شماره 1 بود. هر روش شامل عملگرهایی در یک سطح از انتزاع است. شما نباید عملیات چند سطحی را با هم مخلوط کنید.

6. رسیدگی به خطا.

Exceptions چک شده یا بدون علامت، کدام بهتر است در پروژه استفاده شود (نظر شما چیست؟، نظر بنویسید)؟ من طرفدار چک شده هستم، اما این کتاب کمک می کند تا به استثناهای بررسی نشده از بیرون نگاه کنیم. در واقع، Exception علامت نخورده، امضای متد را مخدوش نمی‌کند، به‌ویژه با توجه به اینکه استثناها چندین لایه را به‌طور هم‌زمان سوراخ می‌کنند. ناراحتی کوچکترین تغییر منجر به تعریف مجدد کل زنجیره روش ها قبل از گرفتن آن می شود که در بسیاری از موارد برای توسعه بسیار ناخوشایند است.

7. قالب بندی کد.

کدهای فرمت شده مناسب نه تنها واضح هستند، بلکه بسیار خوانا هستند. شما بلافاصله ایده ای از براکت ها و اقدامات داخل آن می گیرید. با استفاده از مثال شرایط در ساختارهای if، else، نباید همه چیز را در یک خط بنویسید، بهتر است زنجیره های بلند را جابجا کنید.

8. نفی در شرط.

سعی کنید در شرایط از انکار اجتناب کنید، این بیشتر یک عامل روانی است، مغز ما انکار را به خوبی درک نمی کند و بله! قبل از بیان ممکن است مورد توجه قرار نگیرد. به عنوان مثال، نفی اگر (!condition.isTrue) برای بازنویسی روش بهتر است، آن را بسیار آسان تر می کند (condition.isFalse)

9. توابع باید یک عملیات را انجام دهند.

اگر روش شما عملیات زیادی را انجام می دهد، آنها را به روش های تک عملیاتی تقسیم کنید. پشتیبانی از این روش‌ها بسیار آسان، آزمایش آسان و در صورت لزوم جایگزین یا حذف می‌شوند.

10. خودتان را تکرار نکنید.

کد DRY را تکرار نکنید (خودتان را تکرار نکنید). این یکی از قوانین اساسی است که کد شما را به میزان قابل توجهی کاهش می دهد، آن را در نظر داشته باشید. سعی کنید تمام کدهای تکراری خود را در یک تابع جداگانه قرار دهید. البته، ما می‌توانیم خیلی بیشتر در مورد DRY، KISS(Supd Side)، SOLID ، YAGNI صحبت کنیم. این اصطلاحات برای درک و طراحی ضروری هستند. آنها ارزش یک مقاله جداگانه را دارند، شاید دوباره در مورد آنها بنویسم، زیرا این مقاله به بررسی کتاب "کد پاک" اختصاص دارد. همانطور که قول داده بودید، یک کار کوچک و آسان برای شما. برنامه باید شاخص چاقی را بر اساس داده های داده شده محاسبه کند. تعداد خطاها و رفع خطاها را در کامنت بنویسید. P.S. کد کار می کند و در صورت استفاده صحیح عملکرد خود را انجام می دهد.

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