רווחים:
- יכולת להקים רשת ביטחון לבדיקה אשר לוכדת התנהגות עכשווית לפני הפקטורון מחדש
- היכולת לבקש מ-AI עבור טרנספורמציות קטנות, חד-צעדיות, משמרות התנהגות ולאמת כל שלב
- יכולת לזהות ולתעדף חוב טכני בהקשר עסקי
Refactoring הוא שיפור המבנה הפנימי של קוד מבלי לשנות את ההתנהגות החיצונית שלו: הפיכתו לקריאה יותר, פשוטה יותר, ניתנת לתחזוקה. חוב טכני, לעומת זאת, הוא פשרה עיצובית שנעשתה למען פתרון מהיר והוחזר "בריבית" לאורך זמן - כל פינה שתחתוך היום תחזור מחר כהאטה או באג. בינה מלאכותית היא עוזר רב עוצמה שמאיץ משימות חזרות חוזרות ומכניות; אבל יש כלל זהב אחד של עיבוד מחדש, ובינה מלאכותית לבדה לא יכולה להבטיח זאת: אסור לשנות התנהגות.
ביחידה זו נלמד כיצד לבצע ריפאקטורינג בטוח עם AI: שלבים קטנים והפיכים, הגנה באמצעות בדיקות, זיהוי ריחות קוד ותעדוף חובות טכניים. הנקודה הקריטית היא זו: המעבר במבחנים, לא המילה של ה-AI, הוא שמוכיח שההתנהגות נשמרת.
כלל הזהב של Refactoring: ההתנהגות נשארת קבועה
מה שהופך את הפקטורינג למסוכן הוא שינוי התנהגות שלא ביודעין תוך אמירת "אני משתפר". הפלת מקרה קצה בעת פישוט תנאי, שבירת הסדר בעת הפיכת לולאה, החמצה של תופעת לוואי בעת פיצול פונקציה - כולם מייצרים קוד "נקי למראה" אך שבור.
לכן בדיקה היא תנאי הכרחי ל-refactoring: לפני השינוי, עליך לבצע בדיקות שתופסות התנהגות קיימת. בדיקות אלו מהוות "רשת ביטחון"; אם אתה שובר בטעות משהו במהלך ריפקטור, הם ישברו ויזהירו אותך. אם אין לך מבחנים, כתוב תחילה מבחנים שמתקנים התנהגות קיימת (כפי שלמדנו ביחידה 5) - זה המקום שבו הבינה המלאכותית מקבלת התחלה.
זהירות: Refactoring בסיוע בינה מלאכותית ללא רשת בדיקות הוא אחד המקורות הכי ערמומיים לבאגים. קל לומר "שימרתי את ההתנהגות"; ההוכחה היא שאותם מבחנים עוברים לפני ואחרי השינוי.
שלב אחר שלב: זרימת Refactoring מאובטחת
- הגדר את רשת הביטחון. שיהיו בדיקות שילכוד את ההתנהגות הנוכחית של הקוד שתבצע מחדש; אם לא, רשמו אותם קודם (ותראו אותם עוברים).
- תן שם לריח. מה אתה משפר ולמה? "הפונקציה הזו עושה 3 דברים", "אותו ההיגיון חוזר ב-4 מקומות", "שמות מטעים".
- בקשו צעדים קטנים וצעד אחד. בקש מה-AI טרנספורמציה בודדת (למשל פשוט "לחלק את הפונקציה הזו לשניים"), לא לשכתב את כל הקובץ.
- הרץ את הבדיקות. אחרי כל צעד. אם הוא ירוק, המשך, אם הוא אדום, קח אותו בחזרה.
- קרא את הבדל. אשר שורה אחר שורה שהשינוי אכן משמר התנהגות; ייתכן שיש החלקה לוגית כשאומרים שבינה מלאכותית היא "רק מבנה".
- מאחדים לחתיכות קטנות. יחסי ציבור גדולים חד-פעמיים הם מסוכנים ואינם ניתנים לבדיקה.
שלושה מיני מארזים
מארז 1 - פונקציית 220 שורות מפוצלת בצורה בטוחה. לצוות אחד הייתה פונקציית עיבוד הזמנות של 220 שורות. נכתבו 14 מבחנים ראשונים (בעזרת AI) שתפסו את ההתנהגות הנוכחית, כולם עברו. לאחר מכן הפונקציה חולקה ל-5 פונקציות קטנות יותר צעד אחר צעד על ידי AI; בדיקות נערכו לאחר כל שלב. שני בדיקות נשברו בשלב אחד - הבינה המלאכותית פספסה את החזרה במקרה של קצה. בדיקות תפסו את זה מיד ותיקנו את זה. ללא הרשת, השגיאה הייתה יכולה להגיע עד לייצור.
מקרה 2 - אסון ללא רשת בדיקות. מפתח אחר "ניקה" מודול חישוב תאריכים שלא היו בו בדיקות עם AI. הקוד נראה טוב יותר, אבל הוא חישב את השנה המעוברת בצורה שגויה; הבאג יצא שבועיים לאחר מכן עם תלונת לקוח. ההפסד עלה בהרבה על הזמן שנחסך מהחזרה. לקח: ריפקטור ללא בדיקה הוא הימור.
מקרה 3 - תעדוף חוב טכני. צוות אחד העניק ל-AI צבר של 30 בערך נקודות "ניתנות לשיפור" וכל אחת מהן קלע בציר "תדירות שינוי × סיכון × מאמץ". בטבלה שהתקבלה, מודול מכוער שנגע בו לעתים רחוקות היה למעשה בעדיפות נמוכה, בעוד שמודול במורכבות בינונית שהתחלף לעתים קרובות היה בעדיפות גבוהה. הצוות הפנה את האנרגיה שלו למקום הנכון.
ארבע תבניות הניתנות להעתקה
זיהוי ריח קוד ותעדוף:
רשימת "ריחות" של מועמד מחזיר בקוד זה: פונקציה ארוכה, חזרה (DRYViolation), שם מטעה, מצב מקנן עמוק, תופעת לוואי נסתרת, מספר קסם. לכל אחד: מיקום, מדוע הבעיה, צעד קטן מוצע, סיכון משוער (נמוך/בינוני/גבוה). אל תשנה קוד עדיין, רק תתכנן.{{code}}
שינוי צעד אחד, משמר התנהגות:
פשוט עשה זאת: {{המרה יחידה, למשל. חלק את הפונקציה הזו ל-3 פונקציות קטנות יותר בשם}}. שנה את ההתנהגות הגלויה, ערכי החתימה וההחזרה. כתוב במשפט אחד מדוע כל מה ששינית שומר על ההתנהגות.{{code}}
רשת ביטחון לפני רפקטור (בדיקת אפיון):
כתוב בדיקות שתופסות את ההתנהגות הנוכחית של פונקציה זו (נכונה או לא); המטרה היא לתפוס אם ההתנהגות משתנה במהלך ריפקטור. כלול ערכים טיפוסיים + קצה. כתוב ציפיות על סמך הפלט הנוכחי של הפונקציה.{{function}}
יצירת רישום חובות טכניים (פיגור):
יוצקים את רשימת הריחות הבאה לטבלת סדר עדיפויות: חומר, אזור מושפע, תדירות השינוי (הידע שלי: {{...}}), סיכון, מאמץ משוער, עדיפות מומלצת. שים את ההשפעה הגבוהה + המאמץ הנמוך בראש. {{smell_list}}
הנחיה חלשה / הנחיה חזקה
חלש: "נקה את הקוד הזה ושפר אותו."
חזק: "חלק את הפונקציה הזו בת 90 השורות ל-3 פונקציות קטנות יותר עם אחריות יחידה, מבלי לשנות את ההתנהגות והחתימה החיצונית שלה. שמור את תופעות הלוואי (כותב DB) בסדר הנוכחי. יש לי בדיקות, ההתנהגות צריכה להישאר זהה. תן את ההפרש והסביר במשפט אחד למה כל פיצול שומר התנהגות. [קוד]"
גרסה חזקה; זה דורש טרנספורמציה ספציפית אחת, מטיל במפורש אילוץ התנהגות וחתימה ודורש הצדקה. בקשות מעורפלות כמו "עשה טוב יותר" מובילות לשינויים בלתי מבוקרים ומסוכנים.
סוג Refactoring
אמינות AI
תנאי מוקדם
לשנות שם
גבוה
האם ההיקף נכון?
חלוקת פונקציות
בינוני-גבוה
Testnet הוא חובה
שיתוף חזרה
בינוני
הבדל התנהגות עשוי להיות מוסתר
שינוי אלגוריתם/מבנה
נמוך
בדיקות מקיפות + אימות אנושי
סידור מחדש אדריכלי
נמוך
בהובלת אדם, נתמך בינה מלאכותית
ניהול חוב טכני, לא איפוס
חוב טכני הוא לא הכל רע; לפעמים הלוואה מודעת (כדי לעמוד במשלוח) היא ההחלטה הנכונה. המטרה היא לא לסלק חוב, אלא להפוך אותו לגלוי וניתן לניהול. בינה מלאכותית מהירה באיתור ותעדוף חובות, אבל ההחלטה "איזה חוב צריך לשלם ואיזה צריך לנטוש" דורשת הקשר עסקי: באיזו תדירות מודול זה משתנה, על כמה אנשים הוא משפיע, מה הסיכון? החלטה זו מתקבלת על ידי הצוות שמכיר את בסיס הקוד ואת המוצר; AI רק מבהיר את האפשרויות.
טיפ: שמור על יחסי ציבור המחודשים שלך נפרדים מיחסי ציבור הכרוכים בשינוי התנהגות. היכולת לומר "יחסי ציבור זה רק שינוי, ההתנהגות זהה" מקלה על החקירה ומאפשרת לך לצמצם במהירות את הסיבה אם מתעוררת בעיה.
טעויות נפוצות
- Refactoring ללא testnet. לא נותר לך שום דבר להוכיח שההתנהגות נשמרת.
- זה אומר "נקה את כל הקובץ". שינויים גדולים ובלתי מבוקרים מסתירים את השגיאה ואינם ניתנים לבדיקה.
- קבלת Diff מבלי לקרוא אותו. ייתכן שה-AI החליק מההיגיון כשאמר "רק מבנה".
- מבלבל בין רפקטורינג לשינוי התנהגותי. ביצוע שניהם באותו יחסי ציבור הופך את מעקב שורש לבלתי אפשרי.
- מנסה לתקן כל ריח. קוד מכוער שמשתנה לעיתים רחוקות הוא לרוב בעדיפות נמוכה; הקצו אנרגיה למקום המשתנה בתדירות גבוהה.
לסיכום
הכלל היחיד של ריפקטורינג הוא שההתנהגות נשארת קבועה, וההוכחה לכך היא הבדיקות. בינה מלאכותית היא רבת עוצמה בזיהוי ריחות קוד, טרנספורמציות של צעד אחד ותעדוף חובות טכניים; אבל אתה צריך להגדיר את רשת הביטחון, להריץ את הבדיקות ולקרוא את ההבדל לאחר כל שלב. בצע צעדים קטנים, הפיכים; להבחין בין שינוי התנהגותי מחדש; ולתת לצוות שמכיר את ההקשר העסקי להחליט איזה חוב לשלם.
משימת יישום
בחר פונקציה מבסיס הקוד שלך שנראית לך ארוכה או מורכבת. תחילה הדפס בדיקות שתופסות את ההתנהגות הנוכחית שלה עם תבנית "רשת הביטחון" ובדוק אם כולן עוברות. לאחר מכן בצע מחדש את הפונקציה בצורה יחידה (למשל פיצול לשניים) עם דפוס "טרנספורמציה משמרת התנהגות בצעד אחד" והפעל שוב את הבדיקות. אם מבחן נשבר, גלה מדוע; אם הוא לא נשבר כלל, קרא את ההבדל שורה אחר שורה כדי לוודא שההתנהגות אכן נשמרת.
רשימת בדיקה
- [ ] אני יודע ש-refactoring לא אמור לשנות התנהגות ויש מבחנים שמוכיחים זאת.
- [ ] אני מקים רשת ביטחון שתופס את ההתנהגות הנוכחית לפני הפקטור.
- [ ] אני רוצה טרנספורמציות קטנות וצעד אחד מ-AI, לא חד-פעמיות גדולות.
- [ ] לאחר כל שלב אני מריץ את הבדיקות וקורא את ההבדל.
- [ ] אני ממשיך לשחזר יחסי ציבור בנפרד מיחסי ציבור לשינוי התנהגות.
- [ ] אני מעדיף חוב טכני בהקשר עסקי, לא מנסה באופן עיוור לאפס.