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

בואו ננסה להתמקד רגע ולראות איזה מאפיינים יש לביקורת גרועה ואיך אנחנו יכולים להעביר ביקורת יעילה יותר ב Code Review הבא שלנו:

1. העבירו ביקורת על הקוד - לא על המתכנת

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

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

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

2. שני "כן" על כל "לא"

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

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

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

או במקום להגיד "מי כותב eval בצד השרת!? איפה למדת לכתוב קוד???" נעדיף להגיב במתינות "אני רואה שבחרת להשתמש ב eval כדי לפענח את ה JSON שהגיע מה JavaScript. שימוש כזה ב eval הוא בעיית אבטחה רצינית. אצלנו במערכת מפענחים JSON-ים עם JSON.parse. ואגב יהיה יותר קל להעביר את הפרמטרים האלה בתור רשימה פשוטה במקום בתור JSON".

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

3. היכנסו לראש של מי שכתב את הקוד

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

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

4. הציעו דרך פעולה ברורה לשיפור בהמשך

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

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

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