שינוי ארגון הקוד – הקדמה לריפקטורינג

שינוי ארגון הקוד – הקדמה לריפקטורינג

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

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

באופן דומה, בסיס הקוד של מוצר צריך לעבור ארגון מחדש, שוב ושוב, כדי להתאים לנסיבות משתנות. Class שיש לו יותר ויותר פונקציות צריך להתפצל ל class-ים קטנים יותר, או שיהיה מאוד קשה לתחזק אותו. ביטוי תנאי (If-Else Statement) שגדל למפלצת צריך להצטמצם בחזרה ולהיות קומפקטי, אחרת יהיה מקור לתקלות רבות. מישק שהיה פעם פשוט וגדל והתרחב צריך מעטפת חדשה שתקל על הצרכנים שלו.

אנו קוראים לתהליך של התאמת בסיס הקוד "ריפקטורינג" (refactoring) – שינוי מבנה הקוד, לא כדי לקבל פונקציונליות חדשה אלא כדי שהוא יהיה מותאם יותר לדרישות החדשות שעומדות מולנו – עסקיות וטכניות כאחד.

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

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

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

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

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

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

לפוסט הזה יש תגובה אחת

  1. Ꮤritfe more, thats all I have to ѕay. Literally, it seems
    as though you reliied on the vіdeo to make
    your point. Yoou definitely know what ypure
    talking about, why ᴡaste your intelligence on just posting vidеos to үour weblog when you could be giving us something enlightening to read?

כתיבת תגובה

סגירת תפריט