(חשוב!) על Code Review ועל Peer Review

היי,

אז חלקכם כבר הספקתם לשלוח קוד ל־Code Review (בקיצור: CR), ואתם רואים שזה תהליך ארוך ולא פשוט.
יש כמה דברים שחשוב לי שתקראו כדי לפשט לכולנו את התהליך.

טכני:

1. כשטיפלתם בהערה שנתתי – אם סיימתם לטפל, לחצו על Resolve Issues. אם לא (נניח – לא הבנתם מה אני רוצה מחייכם), כתבו תגובה. בצורה הזו אני אדע לחזור לקוד שלכם ולבדוק אותו שוב.
2. קוד יכול לעבור גם 10 או 20 פעמים CR. זה לאו דווקא בגללכם – לפעמים אני בודק בזריזות ומוצא מספיק הערות לפעם הראשונה, לפעמים אני מפספס דברים, לפעמים באמת הוספתם קוד שיכול לעבור שיפור.

כתיבת Code Review לחברים

1. הֱיוּ נחמדים – זה סופר חשוב, באמת, לא סתם זו הנקודה הראשונה. לקבל CR זו פוזיציה לא נעימה שבה מבקרים יצירת אומנות שכתבת, ולרוב המתכנתים זה נוגע בנקודות רגישות. זכרו שאנשים משקיעים הרבה זמן בלכתוב את הקוד שהם מעלים. תנו פידבקים טובים מדי פעם, תעריכו את העבודה של העמיתים שלכם. לא חייבים להיות ביזנס וקרים, יש פה יחסים קולגיאליים וגם בעבודה “בעולם האמיתי” צריך לדעת איך לתת ביקורת.
2. תעשו CR־ים לחברים שלכם – זה גם מעשיר את פרופיל הגיטהאב שלכם, גם יוצר קשרי עבודה וגם דרך ממש נהדרת ללמוד טריקים חדשים. לא אחת למדתי דברים חדשים בפייתון מלבדוק לכם תרגילים, וזה מעשיר מאוד לדעת להיכנס לקוד של אחרים ולתת ביקורת בונה. אני יודע שזה יחלוף ל־80% מכם מעל הראש, אבל בשלב הזה זו באמת אחת הדרכים הטובות ביותר עבורכם להשתפר, לא סתם הכנסתי את זה כשלב הכרחי השבוע.
3. אם אתם רוצים להשתפר במתן CR, קראו בבקשה את המדריך של גוגל בנושא, ואת המאמר הקצר בבלוג של Stackoverflow.

צ’קליסט לנותן ה־CR

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

קבלת Code Review

1. קחו דברים ברוח טובה. עבור אנשים מסוימים זה לא נעים לקבל דבר שעשוי להתפרש כביקורת מחברים שנמצאים יחד איתכם בקורס – אבל ככה זה גם בעבודה ובמדעים בכלל. Peer Reviews זה דבר חשוב שצריך לקחת כהזדמנות לשיפור עצמי. זו לא ביקורת אישית עליכם. למעשה, חלק מהאנשים שכתבו לכם את ה־CR לא יודעים מי עומד מאחורי ה־PR. למרות שזה קשה, נסו להפריד את היצר הרגשי ולקחת את הביקורת באופן ענייני. אם אתם קולטים שאתם עומדים לחטוא ב־pushback, עצרו לכמה דקות לחשוב אם ניתחתם את ההערה לעומק והאם אולי בכל זאת יש לה מקום.
2. נסו לשלוח ל־CR קטעי קוד קטנים. גם אם לא סיימתם את הפיצ’ר, שלחו ל־CR. הקדימו את הודעת ה־commit במילה: WIP: (זה אומר Work In Progress). זה יבטיח שלא נמרג’ג’ את השינויים שלכם, ושנדע שמדובר בקומיט לא שלם. זה יאפשר לנו לעבור על הקוד שלכם תוך כדי ולמזער את הזמן הכולל שעובר עד שהקוד ימורג’ג’.

אפשר לשלוח Pull Request כדי לקבל CR לפני שהכל מוכן?

כאילו - איך נכון לשלוח קוד לCR?

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

בבקשה אל תסגרו הערות שנתתי אם לא פתרתם אותן.

זו תזכורת כי זה עדיין קורה
יש סיבות מעבר לכך שזה גס־רוח לטאטא מתחת לשטיח הערות אחרי שהשקעתי בבדיקת הקוד:

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

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