כך אני מגיעה מוכנה ל-Code Review

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

למה השמות שבחרתי לא מוצלחים?

למה הקוד שכתבתי לא קריא?

למה המיקום שבחרתי לקוד שלי לא מתאים?

למה המימוש של הפונקציה שלי לא טוב?

איך הפרתי עקרונות של השפה/פרידגמה?

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

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

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

כעת, אני אחזור טיפה אחורה…

---

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

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

כדי לחדד את התחושות שהנושא הזה מעורר בי, אני אנסה להשוות לסיטואציה לא נוחה אחרת – קריוקי! 

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

לא הבנתן איך זו מטאפורה מושלמת לקוד? אני אסביר. 

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

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

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

בכל פעם שהיו עושים לי Code Review עברתי הערה הערה,הפכתי אותן לכללי עשי/אל תעשי, והוספתי אותן למסמך. כך, לפני שהייתי מעבירה קוד לבדיקה, הייתי עוברת על הקוד לצד המסמך ומנסה לאתר בעיות.

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

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

---

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

לאחרונה שחררתי את הפיצ’ר הרציני הראשון שלי בסקאלה, ובהתאם ביקשתי מכל מתכנתי הסקאלה בחברה לבדוק את ה-PR שלי כדי שאקבל כמה שיותר הערות ואוכל ללמוד מהן.
כמה מתכנתים נחמדים עשו לי Code Review, וכשפתחתי אותו לראשונה קצת רציתי למות. כל הקוד שכתבתי במאמץ רב ומתוך ניסיון כנה לעשות עבודה טובה היה מלא בהערות. 

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

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

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

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

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

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

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

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

למה השמות שבחרתי לא מוצלחים?

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

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

למה הקוד שכתבתי לא קריא?

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

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

למה המיקום שבחרתי לקוד שלי לא מתאים?

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

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

למה המימוש של הפונקציה שלי לא טוב?

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

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

איך הפרתי עקרונות של השפה/פרידגמה?

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

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

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

---

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

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

הערות:

Featured photo by Johnson Wang on Unsplash