רוברט מרטין, קוד נקי. סקירה של הספר על "קוד קונג פו" למפתחים

שלום ג'אווארשביטים! מאמר זה הוא סקירה של הספר "קוד נקי" מאת רוברט מרטין. יחד נבחן דרכים לשפר ולייעל את הקוד שלך, ובסוף מחכה לך משימה קטנה אך מעניינת. בכל יום, כאשר אנו פותחים את עורך הקוד שלך, אנו מתמודדים עם מחלקות, פונקציות ומשתנים רבים. האפשרות הטובה ביותר היא אם זה הקוד שלך שנכתב מאפס, נכתב פעם אחת, יש בו מעט שורות, אתה עובד עליו לבד, אין עריכות ואין תמיכה נוספת מהלקוח. אבל! כפי שמראה בפועל, כן, אני חושב שאתה בעצמך מבין שזה לא קורה. בעיקרון, נצטרך איכשהו ליצור אינטראקציה עם חברי הצוות שלנו, לשמור על הקוד "הינדו" ולנתח מוצרים למיליוני שורות. לא פעם שמעתי תשובות כאלה מעמיתיי לאימון: "הקוד הזה נכתב על ידי, ואני לא מתכוון להראות אותו לאף אחד", אבל כשאני רואה בקשות לעזרה לעזרה עם קוד כזה, זה לוקח הרבה זמן זמן (לפעמים ממש הרבה זמן) להתעמק ולהבין מה האדם רצה להגיד לי, אני אפילו רוצה להגיד "למחוק ולכתוב שוב"! העריכו את הזמן והאנרגיה של אנשים שרוצים לעזור לכם, כתבו נכון, ואם אינכם יודעים כיצד, אף פעם לא מאוחר מדי ללמוד. ספרו של רוברט מרטין בולט בין ספרים בפורמט זה בכך שהוא מכיל דוגמאות רבות בג'אווה. זו אולי אמירה קצת פנאטית מצידי, אבל היא נכתבה בסגנון OOP, כלומר בכתיבת חלקים וקטעים. קל להבנה ולקריאה, הספר קל לקריאה תוך כדי תנועה או בערב לפני השינה. Clean Code מחולק ל-3 חלקים. בחלק הראשון אנו מתבקשים לעבור על תורת הספר, ללמוד על דפוסי עיצוב וכללי נימוסים טובים. החלק השני מזמין אותנו לתרגל ריפקטור וכתיבה, והחלק השלישי הוא הסיכום הסופי של הקוד "מריחות" בדוגמאות. ובכן, המחבר נגע בנושאים רבים שעבורם תצטרכו בעיקר ידע ב-Java Core, אך ישנם גם קטעים המוקדשים ל-JUnit Unit Tests, Log4j Logging, הכרת התבניות הפשוטות ביותר בעיצוב (אבל כפי שאמרתי למעלה, אין רבים מהם, וכל מה שלא מובן אפשר לחפש בהצלחה בגוגל, כן ולנתח אותו בקורס JavaRush). כל פרקי הספר אינם קשורים זה לזה; אתה יכול להתחיל לקרוא בהצלחה מהפרק שאתה אוהב. סיכום קצר של הרעיונות המרכזיים שהעליתי מהספר. אודה להערותיך עליהם, בהן תוכל לחלוק את החזון שלך לגבי ההצהרות הללו.

1. הערות == רוע.

ברוב המקרים, הערות הן קביים שבעזרתם אנו מנסים לכסות את הקוד הרע שלנו. ובמקרים מסוימים, הם גם משקרים לגבי מטרתן של שיטות או משתנים אם יש שינוי קוד מתמיד.

2. קוד הערה, קוד מת.

השארת פיסות הקוד האלה באפליקציה שלך היא בגדר זבל. קוד לא בשימוש מצטבר עם הזמן ומפריע לניקיון האפליקציה שלך, בדוק את הקוד עבור מודולים כאלה מעת לעת.

3. כותרות של שיטות, מחלקות ומשתנים.

כדאי לדון בנושא זה במאמרים נפרדים. אל תתעצלו ותכתבו שמות שיכולים לספר על מטרתם. למד כמה תקנים בכותרות איות. נושא זה הוא "חובה" ללימוד מפורט.

4. לכל שיטה ומשתנה יש את מקומו בהיררכיית המחלקות.

בדרך כלל, למחלקה יכולים להיות משתנים ושיטות (סטטיים ולא סטטיים), בנאי, מחלקות מקוננות ופנימיות ומונים. בקיצור, יש הרבה מידע, ויש צורך לקבוע את מקומו של כולם בכיתה. אם תסתכלו על מחלקות הליבה של java, תראו שהמבנה בנוי בצורה ברורה, אנחנו יכולים לראות כל חלק במקומו, כמובן שבפרוייקטים שלכם זה יכול להשתנות בתוך הפרויקט, אבל לא בכל מחלקה. לעצמי הגדרתי את מבנה הבנייה הבא: בתחילת המחלקה יש לי משתנים סטטיים, ואז משתני אובייקט + Enums אם הם קיימים. אחרי המשתנים, אני מגדיר את בנאי המחלקות. אחר כך אני כותב שיטות לעבודה עם הכיתה. אחרי השיטות אני כותב גטרים וקובעים. ובסוף יש לי שיעורים פנימיים. אתה יכול להשתמש במבנה שלי או לכתוב משלך בתגובות.

5. רמות הפשטה של ​​שיטות.

עבורי זו הייתה תגלית מס' 1. כל שיטה מכילה אופרטורים ברמת הפשטה אחת בלבד. אתה לא צריך לערבב פעולות מרובות רמות יחד.

6. טיפול בשגיאות.

חריגים מסומנים או לא מסומנים, מה עדיף להשתמש בפרויקט (מה דעתך?, כתוב הערות)? אני תומך ב-checked, אבל הספר עוזר להסתכל על חריגים לא מסומנים מבחוץ. ואכן, חריגה שאינה מסומנת אינה מעוותת את חתימת השיטה, במיוחד בהתחשב בכך שחריגים "נוקבים" מספר שכבות בבת אחת. אי הנוחות של השינוי הקטן ביותר מובילה להגדרה מחדש של כל שרשרת השיטות בטרם תופסים אותה, מה שמאוד לא נוח לפיתוח במקרים רבים.

7. עיצוב קוד.

קוד בפורמט נכון הוא לא רק ברור, אלא גם קריא מאוד. אתה מקבל מיד מושג על הסוגריים והפעולות בפנים. באמצעות הדוגמה של תנאים ב-if, else constructs, לא כדאי לכתוב הכל בשורה אחת, עדיף להעביר שרשראות ארוכות.

8. שלילות בתנאי.

נסו להימנע מהכחשה בתנאים, זה יותר גורם פסיכולוגי, המוח שלנו לא תופס הכחשה טוב, וכן! לפני שאולי לא ישים לב לביטוי. לדוגמה, שלילת אם (!condition.isTrue) עדיף לשכתב את השיטה, זה יקל הרבה יותר ככה (condition.isFalse)

9. על הפונקציות לבצע פעולה אחת.

אם השיטה שלך מבצעת פעולות רבות, חלק אותן לשיטות פעולה בודדות. שיטות אלו קלות מאוד לתמיכה, קלות לבדיקה, ובמידת הצורך, מוחלפות או מוסרות.

10. אל תחזור על עצמך.

אל תחזור על הקוד DRY (אל תחזור על עצמך). זהו אחד הכללים הבסיסיים שיפחיתו את הקוד שלכם באופן משמעותי, קחו זאת בחשבון. נסה להכניס את כל פיסות הקוד החוזרות לפונקציה נפרדת. כמובן, אנחנו יכולים לדבר הרבה יותר על DRY, KISS(Keep it simple Stupid), SOLID , YAGNI. מונחים אלו חיוניים להבנה ולעיצוב. הם שווים מאמר נפרד, אולי אכתוב עליהם שוב, מכיוון שמאמר זה מוקדש לביקורת על הספר "קוד נקי". כמובטח, משימה קטנה וקלה עבורך. על התוכנית לחשב את מדד ההשמנה בהתבסס על הנתונים הנתונים. רשמו בתגובות את מספר השגיאות והתיקונים בקוד. נ.ב. הקוד עובד ומבצע את תפקידו אם נעשה בו שימוש נכון.

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