מי שמקצועו כתיבת קוד ומתיחס ברצינות למקצוע שלו, יודע שכמו כל תחום התמחות, כתיבת קוד היא נושא הרבה יותר רחב, ממה שנראה במבט ראשון. מונחים מתחום הספרות כמו סגנון, מטבעות לשון, ניבים, שימוש נכון בשפה, איכות הכתיבה, בהירות, ברירות ויופי, הם מונחים, שכותבי קוד מקצועיים, יכולים להתוכח עליהם, בלהט דתי שלא היה מבייש פעילי שמאל, ימין ודתיים, במפגש המוקדש לנושא מי צודק באי"ה.
כל כותב קוד מקצועי, שנכנס לקוד של מישהו אחר, נתקף ישר בתחושה של אי נוחות ( לפעמים ממש עד כדי כאב). תשמע ממנו התיחסויות בנוסח: הקוד לא כתוב נכון, אני הייתי כותב את זה אחרת, יותר יפה, יותר אלגנטי, יותר נכון וכו'. התחושה יכולה לתקוף מקודד מקצועי גם בהסתכלות על הקוד שהוא עצמו כתב, ולפעמים אפילו כמה דקות לאחר שכתב אותו (תלוי כמובן ביחס ישר למידת הסכלורוטיות שלו ולגודל האגו שלו).
לפני לא הרבה זמן, התחושות הללו היו מתורגמות לתיסכול, שהוביל בדרך כלל לאלימות כלפי הסביבה. מה שאיפשר לאתר בקלות רבה מקודדים מקצועיים באמת, לפי קצב החלפת לוח המקשים שלהם, או על ידי שימוש באמצעים פחות אמינים, כמו מדידת עצמת הרעש של ההקלדה.
הסיבה לתיסכול נבעה מזה שאם רצית לעשות משהו פשוט, כמו לשנות שם של משתנה מ X17 למשהו יותר ברור כמו AgeOfSystem, היית צריך לחפש ידנית את כל המופעים שבהם המחרוזת X17 מופיעה, לבדוק שאתה משנה לשם החדש רק את אלה שב Scope הנכון, שאין Side Effects לשינוי, ולבסוף לבצע סט בדיקות QA מלא ממש כמו שינוי של Feature במוצר. בקיצור כאב ראש רציני שאך מנהל פרויקט לא היה מאשר לך לבצע בקוד רק בגלל שהוא "לא מספיק יפה". וזה עוד על משהו פשוט, לקחת קטע קוד, שחוזר על עצמו כמה פעמים ב Switch, ולהוציא אותו לפונקציה חיצונית, דרש בדרך כלל Redesign של היישום.
אם ננסח יותר מדעית את הגורם לתיסכול, הסיבה העיקרית נבעה מחוסר לקבל תשובה מוסמכת, על מה יהיו ההשפעות של השינוי, על כל מקומות בקוד. לצורך זה היה צריך להשתמש בכלי עריכה שיודעים לא רק להחליף מחרוזות, אלא גם להבין דברים שבאים מתחום הקומפילציה, כמו ההקשר וה Scope של השינוי.
כלי הפיתוח המודרניים, כבר די הרבה זמן, מבצעים הידור תוך כדי הכתיבה, ומסמנים שגיאות. מכאן לא גדול המרחק לצפות שהם באותה הזדמנות גם יסמנו לעצמם פרמטרי קומפילציה נוספים, וינתחו לך לא רק איזה פונקציות אחרות יהיו מושפעות מהשינוי, אלא אפילו איזה שגרות בדיקה יושפעו מהשינוי. היכולת של Visual Studio 2010 לסמן לך על כל שינוי איזה Unit Tests מושפעות ממנו זו רק דוגמא אחת.
התהליך של לקחת קוד קיים, ולשפר את איכותו, מבלי להשפיע על הלוגיקה של היישום או הפונקציונאליות שלו נקראת Refactoring. וזה היה נושא ההרצאה של אורי לביא במפגש האחרון של קבוצת המשתמשים של מפתחי NET..
אני מאד נהניתי מההרצאה. אורי זרם עם החומר והיה ניכר שהוא מכיר אותו היטב. לאחר שהוא כיסה את היסודות הבסיסיים, הוא עבר להדגמה, ולקח אותנו לאורך דוגמא של קוד ספגטי סטנדרטי שכתוב ממש רע, שנהפכה לאט לאט ובשלבים, לקוד הרבה יותר אלגנטי, הרבה יותר קל לתחזוקה, וגם Self Documented. אורי הסביר, הדגים ובדקכל שלב בתהליך. ולאחר ההפסקה קיבלנו לקינוח רשימה של סימני סירחון שיכולים להצביע על נקודות בקוד שדורשות שיפור.
אז הנה כמה נקודות מההרצאה וכמה הערות ותובנות.
ללא ההתפתחות והתמיכה של כלי הפיתוח והתמיכה שלהם בנושא, כל נושא ה Refactoring היה נשאר תיאורטי עוד הרבה שנים. ההתפתחות בכלי הפיתוח היא הגורם העיקרי שהפך את ה Refactoring לשווה לכל נפש.
ה Refactoring זה תהליך מובנה שיש לו כללים, אתה לא חייב לציית לכולם, יש כללים חשובים יותר ויש כללים חשובים פחות. אבל זה לא משהו חופשי, שמתעסק באומנות מופשטת, אלא תורה סדורה עם כללים והנחיות.
חשוב להדגיש ש Refactoring זה לא "בוא נכתוב את הכל מחדש כמו שצריך". זה גם לא שם אחר ל Redesign של המערכת. נתקלתי כבר יותר מפעם אחת, בזה שמשתמשים במילת הקסם Refactoring מול הלקוח, כאמצעי לחפות על כתיבה מחדש של מערכת, או תכנון מחדש של ארכיטקטורה. ה Refactoring לא אמור להתעסק ב Design של המערכת ולא אמור להוסיף או לשנות לה פונקציונאליות. זה פשוט תהליך איטרטיבי, שמשפר את איכות הקוד.
שימוש לא נכון במונח, גורם לכך שמנהלי פיתוח לא משלבים אותו בתהליכי ה Code Review שלהם, ולקוחות שעברו את החוויה של שימוש לא נכון בשם, מתנגדים לזה שבתי תכנה יקדישו לזה זמן. שני הכיוונים האלה לא נכונים, כי הם פוגעים בסופו של דבר באיכות הקוד.
אסור להתחיל ב Refactoring, אם אין לך מערך שלם של Unit Tests, הנותן כיסוי טוב לקוד שעובר Refactoring. אורי הדגיש את הנושא הזה, וגם הדגים אותו בפנאטיות רבה לאורך כל ההדגמות שלו.
עיקרון פרטו עובד גם ב Refactoring. ביצוע Refactoring הוא לא מטרה בפני עצמה, אלא משהו שאתה עושה במקביל לתהליך הפיתוח הרגיל שלך. אם אתה מוצא את עצמך עושה רק Refactoring משהו פה לא בסדר.
כמו כל תהליך מובנה, יש מאחוריו מטרה והיא צריכה להיות ברורה למי שמשתמש בכלי. וכאן אני חוזר קצת לתחילת הפוסט, לנושא מלחמת הדתות ולעניין האומנותי. אורי היה בהדגמה שלו מאד בעד סמנטיקה של Functional עם דגש על המרה לאופרטורים, גם במחיר של קריאה כפולה לאופרטור בשתי נקודות קרובות וגם במחיר של פגיעה בביצועים. הוא גם היה מספיק הוגן להדגיש, שלא צריך ליישם כל Smell, ושאתה חופשי לקחת החלטות בהתאם למה שמתאים לך. הוא גם הדגיש שבמקרה שלו הוא יודע לאן הוא רוצה להגיע, ולכן גם אם הוא לא יכול להסביר את מה שהוא עושה באותה נקודת זמן, העתיד יוכיח שהוא צדק.
חשוב להדגיש שהמטרה אליה רוצים להגיע, יכולה להיות נושא לויכוח אומנותי או מקצועי מהותי. ההחלטות שאורי לקח לאורך הדרך, באמת התאימו לדוגמא שהוא נתן ולמטרה שהוא רצה להגיע, אבל בעולם האמיתי יכולים להיות מטרות אחרות.
מה שמוליך לנקודה שאני רוצה להדגיש. החלטה על מדיניות ה Refactoring היא לא ברמה של המתכנת. מישהו מאד בכיר במערכת, ברמה של ארכיטקט ראשי או CTO, הם אלה שצריכים להחליט איזה סגנון של קוד הם רוצים לקבל לאורך תהליך הפיתוח, ובהתאם לזה להחליט מראש עבור המקודדים למשל איזה Smells הם חובה ומאיזה יש להתעלם. הנושא הזה צריך להיות חלק מה Coding Guidelines של המערכת. זה נושא שההשפעות שלו כל כך מהותיות על הפרויקט, שהכיוון שלו, אינו נושא לאילתור.
כהערת אגב. במחשבה ראשונה זה מאד משעשע, שיש Smell שאומר, שאם יש הערות בקוד, זה סימן לא טוב, כי הקוד אמור לתעד את עצמו, ואם הוא לא עושה את זה, זה לא טוב. עד כמה שזה נשמע פרובוקטיבי, זה משפט מאד נכון, שמחזיר אותנו לנושא של קידוד כאומנות, ושל קידוד כמקצוע.
מי שלא בא הפסיד. זו היתה הרצאת חובה לכל מי שעוסק בקידוד, והשקפים (שאין לי בשלב הזה שום מושג איפה הם) לא יתנו את מה שנתנה ההדגמה.
מי שלא רוצה להפסיד מפגשים מענינים, שילך לאתר הארועים של מיקרוסופט לפחות פעם בשבוע כדי לבדוק מה הארועים שצפויים. רוב מנהלי קבוצות המשתמשים מקפידים לדווח על המפגשים שלהם שם.