איך עובד ריפאקטורינג ב-Java

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

Refactoring בקורס JavaRush

קורס JavaRush מכסה את נושא ה-refactoring פעמיים:

• אתגר גדול ברמה 5 של קווסט Multithreading ;
• הרצאה על refactoring ב- Intellij IDEA ברמה 9 של קווסט של Java Collections .

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

מה זה refactoring?

זהו שינוי במבנה הקוד מבלי לשנות את הפונקציונליות שלו. לדוגמה, יש שיטה שמשווה 2 מספרים ומחזירה אמת אם הראשון גדול יותר, ו- false אחרת:

public boolean max(int a, int b) {
    if(a > b) {
        return true;
    } else if(a == b) {
        return false;
    } else {
        return false;
    }
}

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

public boolean max(int a, int b) {
     return a>b;
}

כעת שיטה זו נראית פשוטה ואלגנטית, למרות שהיא עושה את אותו הדבר כמו הדוגמה לעיל. כך עובד ה-refactoring: הוא משנה את מבנה הקוד מבלי להשפיע על המהות שלו. ישנן שיטות וטכניקות ריפאקטוריון רבות, אשר נשקול בפירוט רב יותר.

מדוע יש צורך בעיבוד מחדש?

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

1. Refactoring משפר את ההבנה של קוד שנכתב על ידי מפתח אחר;
2. עוזר למצוא ולתקן שגיאות;
3. מאפשר לך להגביר את מהירות פיתוח התוכנה;
4. בסך הכל משפר את הרכב התוכנה.

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

"ריח קוד"

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

אלמנטים גדולים שלא לצורך

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

כיתה גדולה

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

שיטה גדולה

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

1. אם, בעת כתיבת שיטה, אתה רוצה להוסיף הערה לקוד, עליך להפריד את הפונקציונליות הזו לשיטה נפרדת;
2. אם מתודה לוקחת יותר מ-10-15 שורות קוד, עליך לזהות את המשימות ותתי המשימות שהיא מבצעת ולנסות להפריד את המשימות לשיטה נפרדת.

מספר דרכים לבטל שיטה גדולה:

• הפרד חלק מהפונקציונליות של שיטה לשיטה נפרדת;
• אם משתנים מקומיים לא מאפשרים לך לחלץ חלק מהפונקציונליות, אתה יכול להעביר את האובייקט כולו לשיטה אחרת.

שימוש בסוגי נתונים פרימיטיביים רבים

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

רשימה ארוכה של אפשרויות

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

קבוצות נתונים

קבוצות נתונים הקשורות מבחינה לוגית מופיעות לעתים קרובות בקוד. לדוגמה, פרמטרי חיבור למסד הנתונים (URL, שם משתמש, סיסמה, שם סכימה וכו'). אם לא ניתן להסיר שדה אחד מרשימת האלמנטים, הרי שהרשימה היא קבוצת נתונים שיש למקם במחלקה נפרדת (בחירת מחלקה).

פתרונות שמקלקלים את הקונספט של OOP

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

סירוב ירושה

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

הצהרת switch

מה יכול להיות רע במפעיל switch? זה רע כשהעיצוב שלו מורכב מאוד. זה כולל גם בלוקים מקוננים רבים if.

שיעורים חלופיים עם ממשקים שונים

כמה מחלקות למעשה עושות את אותו הדבר, אבל השיטות שלהן נקראות אחרת.

שדה זמני

אם המחלקה מכילה שדה זמני שהאובייקט צריך רק מדי פעם, כאשר הוא מלא בערכים, ובשאר הזמן הוא ריק או חלילה, nullאז הקוד "מריח", ועיצוב כזה מפוקפק. הַחְלָטָה.

ריחות שמקשים על השינוי

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

היררכיות ירושה מקבילות

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

חלוקת תלות אחידה

בעת ביצוע שינויים כלשהם, עליך לחפש את כל התלות (השימושים) של מחלקה זו ולבצע שינויים קטנים רבים. שינוי אחד - עריכות בשיעורים רבים.

עץ שינויים מורכבים

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

"ריח זבל"

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

מספר רב של הערות בשיטה

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

שכפול קוד

מחלקות או שיטות שונות משתמשות באותם בלוקים של קוד.

שיעור עצלן

הכיתה מקבלת מעט מאוד פונקציונליות, אם כי הרבה ממנה תוכננו.

קוד לא בשימוש

מחלקה, שיטה או משתנה אינם בשימוש בקוד והם "משקל מת".

צימוד מוגזם

קטגוריית ריחות זו מאופיינת במספר רב של חיבורים מיותרים בקוד.

שיטות צד שלישי

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

אינטימיות לא מתאימה

מחלקה משתמשת בשדות שירות ובשיטות של מחלקה אחרת.

שיחות כיתה ארוכות

מחלקה אחת מתקשרת לאחרת, שמבקשת נתונים מהשלישית, מהרביעית וכו'. שרשרת כה ארוכה של שיחות פירושה רמה גבוהה של תלות במבנה המעמד הנוכחי.

מחלקה-משימות

יש צורך בכיתה רק כדי להעביר משימה לכיתה אחרת. אולי צריך להסיר אותו?

טכניקות שחזור

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

בחירת כיתה

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

class Human {
   private String name;
   private String age;
   private String country;
   private String city;
   private String street;
   private String house;
   private String quarter;

   public String getFullAddress() {
       StringBuilder result = new StringBuilder();
       return result
                       .append(country)
                       .append(", ")
                       .append(city)
                       .append(", ")
                       .append(street)
                       .append(", ")
                       .append(house)
                       .append(" ")
                       .append(quarter).toString();
   }
}

זה יהיה רעיון טוב למקם את המידע והשיטה של ​​הכתובות (התנהגות עיבוד נתונים) במחלקה נפרדת:

class Human {
   private String name;
   private String age;
   private Address address;

   private String getFullAddress() {
       return address.getFullAddress();
   }
}
class Address {
   private String country;
   private String city;
   private String street;
   private String house;
   private String quarter;

   public String getFullAddress() {
       StringBuilder result = new StringBuilder();
       return result
                       .append(country)
                       .append(", ")
                       .append(city)
                       .append(", ")
                       .append(street)
                       .append(", ")
                       .append(house)
                       .append(" ")
                       .append(quarter).toString();
   }
}

בחירת שיטה

אם ניתן לקבץ פונקציונליות כלשהי בשיטה, יש למקם אותה בשיטה נפרדת. לדוגמה, שיטה המחשבת את השורשים של משוואה ריבועית:

public void calcQuadraticEq(double a, double b, double c) {
    double D = b * b - 4 * a * c;
    if (D > 0) {
        double x1, x2;
        x1 = (-b - Math.sqrt(D)) / (2 * a);
        x2 = (-b + Math.sqrt(D)) / (2 * a);
        System.out.println("x1 = " + x1 + ", x2 = " + x2);
    }
    else if (D == 0) {
        double x;
        x = -b / (2 * a);
        System.out.println("x = " + x);
    }
    else {
        System.out.println("Equation has no roots");
    }
}

בואו נעביר את החישוב של כל שלוש האפשרויות האפשריות לשיטות נפרדות:

public void calcQuadraticEq(double a, double b, double c) {
    double D = b * b - 4 * a * c;
    if (D > 0) {
        dGreaterThanZero(a, b, D);
    }
    else if (D == 0) {
        dEqualsZero(a, b);
    }
    else {
        dLessThanZero();
    }
}

public void dGreaterThanZero(double a, double b, double D) {
    double x1, x2;
    x1 = (-b - Math.sqrt(D)) / (2 * a);
    x2 = (-b + Math.sqrt(D)) / (2 * a);
    System.out.println("x1 = " + x1 + ", x2 = " + x2);
}

public void dEqualsZero(double a, double b) {
    double x;
    x = -b / (2 * a);
    System.out.println("x = " + x);
}

public void dLessThanZero() {
    System.out.println("Equation has no roots");
}

הקוד של כל שיטה נעשה הרבה יותר קצר וברור.

העברת כל החפץ

כשקוראים למתודה עם פרמטרים, לפעמים אתה יכול לראות קוד כזה:

public void employeeMethod(Employee employee) {
    // Некоторые действия
    double yearlySalary = employee.getYearlySalary();
    double awards = employee.getAwards();
    double monthlySalary = getMonthlySalary(yearlySalary, awards);
    // Продолжение обработки
}

public double getMonthlySalary(double yearlySalary, double awards) {
     return (yearlySalary + awards)/12;
}

בשיטה employeeMethodמוקצים עד 2 שורות להשגת ערכים ואחסוןם במשתנים פרימיטיביים. לפעמים עיצובים כאלה לוקחים עד 10 שורות. הרבה יותר קל להעביר את האובייקט עצמו לשיטה, משם אתה יכול לחלץ את הנתונים הדרושים:

public void employeeMethod(Employee employee) {
    // Некоторые действия
    double monthlySalary = getMonthlySalary(employee);
    // Продолжение обработки
}

public double getMonthlySalary(Employee employee) {
    return (employee.getYearlySalary() + employee.getAwards())/12;
}

פשוט, קצר ותמציתי.

קיבוץ לוגי של שדות והצבתם במחלקה נפרדת

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

מדוע ריפקטורינג יעיל

התוצאה של רפקטורינג טוב היא תוכנית שקל לקרוא את הקוד שלה, שינויים בלוגיקת התוכנית לא הופכים לאיום, והכנסת תכונות חדשות לא הופכת לגיהנום של ניתוח קוד, אלא פעילות נעימה למשך כמה ימים. . אין להשתמש ב-refactoring אם יהיה קל יותר לשכתב את התוכנית מאפס. לדוגמה, הצוות מעריך את עלויות העבודה עבור ניתוח, ניתוח ושחזור קוד גבוהות יותר מאשר עבור הטמעת אותה פונקציונליות מאפס. או שהקוד שצריך לשחזר יש הרבה שגיאות שקשה לנפות באגים. לדעת איך לשפר את מבנה הקוד היא חובה בעבודתו של מתכנת. ובכן, עדיף ללמוד תכנות Java ב- JavaRush - קורס מקוון עם דגש על תרגול. 1200+ משימות עם אימות מיידי, כ-20 מיני-פרויקטים, משימות משחק - כל זה יעזור לך להרגיש בטוח בקידוד. הזמן הטוב ביותר להתחיל הוא עכשיו :)

משאבים לצלילה נוספת לתוך refactoring

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

1. "דפוסי עיצוב" - מאת אריק פרימן, אליזבת פרימן, קתי סיירה, ברט בייטס מהסדרה Head First;
2. "קוד קריא, או תכנות כאמנות" - דסטין בוסוול, טרבור פאוצ'ר.
3. "קוד מושלם" מאת סטיב מקונל, שמתאר את עקרונות הקוד היפה והאלגנטי.

ובכן, כמה מאמרים על refactoring:

1. משימה לעזאזל: בואו נתחיל לשחזר קוד מדור קודם ;
2. ארגון מחדש ;
3. Refactoring לכולם .