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

1. הראשונה היא שימוש דוגמטי ב Best Practices, כי אם אין לך זמן לעבור על קוד ובכל זאת לא נעים לא להגיד כלום, אז אתה תעיר על הדברים הקטנים שקופצים לעין (למה אין שתי שורות רווח לפני הפונקציה? הקומפוננטה הזאת עושה יותר מדי וכו).

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

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

1. באיזו תדירות אני מעביר או מקבל הערות ששינו את ה Design של הפיצ'ר בצורה משמעותית?

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

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

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