כמהנדס תוכנה זוטר, עיינתי תמיד בהערות על סקירת קוד שקיבלתי כדי ללמוד כיצד להיות קודאי טוב יותר. אבל כשהגיע הזמן שאנסה לבדוק את הקוד הראשון שלי, הבנתי שהניסיון שלי לא הכין אותי להיות בצד השני.
פיתחתי מקרה חמור של תסמונת התחזה, כשהוא מסתובב כלפי מטה עם שאלות: האם עלי להגיב על שורת הקוד הזו או שזה לא שווה את זה? האם עלי למצוא מאמרים שתומכים בכל תגובה? האם לקרוס את האתר על ידי אישור זה? הם ישנאו אותי? אוקיי, אני מודה שאני מסתובבת די מהר. אבל אחרי שדיברתי עם כמה עמיתים לעבודה, ידעתי שאני לא לבד בדאגות שלי.
מהנדסי תוכנה ג'וניור עשויים להיזרק לבחינת קוד בהנחה המקבילה ל"אתה יודע לקרוא ספר כדי שתדע לכתוב ספר, וזה לא נכון, "אומרת ג'סיקה רודר, מהנדסת ניסיון ב- GitHub.
יש ציפיות שמגיעות עם סקירת קוד, והתהליך יכול להיות מורט עצבים. אז ראיינתי שבעה מהנדסי תוכנה נוספים כדי לאסוף טיפים לבניית הלך הרוח הסוקר.
1. חשבו על ההשפעה הכוללת
באופן כללי, בקשת משיכה טובה (PR) צריכה להשפיע רק על חלק מוגבל מבסיס הקוד. עם זאת, ההיקף המוגבל לא אמור למנוע מכם לחשוב על שינוי הקוד בהקשר של בסיס הקוד הגדול יותר.
נייג'ל מונוז, לשעבר מהנדס ערימה מלאה ב- The Muse ומהנדס תוכנה פרילנסר כיום, מעודד את הסוקר לחשוב "כיצד השינוי הזה משפיע על התמונה הגדולה והקטנה יותר." בהתחשב בתמונה הגדולה יותר כוללת מציאת כל חוב טכני - חפש קוד זה חוזר, לא מודולרי, או שאינו דבק במוסכמות הסטנדרטיות העדכניות ביותר - וכן ניתוח שינויים בארכיטקטורה של בסיס הקוד.
סם דונוב, מפתח ליבה בחברת הדסון נהר המסחר, מאמין כי "אין דבר גדול מדי או קטן מכדי להגיב עליו. הצעות לשיפורים קטנים עשויות להוביל לשיפורים גדולים יותר בחלקים מרובים של קוד הקוד. "
אתה יכול להשתמש בהערת יחסי ציבור ב- GitHub כדי לספק משוב חיובי, כמו גם לציין היכן הקוד עשוי להיות שונה מהמוסכמות הרגילות של React.
לדוגמה, במהלך אחת מביקורות הקוד שלי, קיבלתי תגובה שמאפיינים מסוימים על רכיב React מבלבלים, מה שהעלה שאלות רחבות יותר לגבי אופן השימוש של הרכיב. בסופו של דבר הסרתי את המאפיינים מהרכיב המקורי ויצרתי רכיב נפרד כדי להבהיר את התנהגותו של כל אחד מהם ולהבטיח שאפשר להשתמש בשניהם במקומות נוספים.
2. שקול ביטחון
אל תשכח כי שינויים מסוימים עשויים להשפיע יותר מאשר רק על בסיס הקוד. רודר ממליץ להעריך אם משתמש "יכול להשתמש בפונקציונליות זו כדי להטריד מישהו או יכול להתעלל במערכת." לדוגמה, אם התכונה החדשה בבקשת המשיכה כוללת הזנת משתמש, חפש הזרקת SQL, גישה לנתונים, סקריפטים בין אתרים, ו פגיעויות אבטחה אחרות.
3. התמקדו באגים
תורמי הקוד שלך - לא משנה כמה הם עשויים להיראות רובוטיים - הם אנושיים, ובני אדם עלולים לשבור או לשכוח פונקציונליות. אז וודא שאתה "עיין במבחנים באותה חשיבות כמו שאר הקוד", מייעץ אבהישק פילאי, מוביל טכנולוגי במורים לשכר המורים. "הם ימנעו באגים חדשים וישמשו כסוג של תיעוד לכל אחד אחר שעובד על זה בעתיד."
קריאת הבדיקות יכולה לעזור לך להבין את הפונקציונליות של תכונה חדשה ולראות את המקרים השונים שהיא תציג, ואילו ניתוח הבדיקות יכול לעזור לך להצביע על מקרים חסרים ולמצוא תכונות שאינן כלולות ביחסי ציבור זה. אם אין בדיקות הכלולות בשינוי הקוד והן נראות רלוונטיות, ראוי לבקש אותן במסגרת הסקירה.
אבל מבחנים הם לא הכל. "אל תשים יותר מדי אמון במערכת", מזהיר דונוב. "רק בגלל שהבדיקות רצו לא אומר שאין באגים."
אולי תרצה גם "להפעיל את האפליקציה באופן מקומי כדי לבדוק אותה באופן פונקציונאלי ולוודא שהיא פועלת. אם זה לא עובד, אין טעם לבחון עוד יותר, "אומר ריאן ורנר, מפתח תוכנה בחברת שמונה אור. למרות שחלק מהסוקרים לא חושבים שבדיקה ידנית צריכה להיות חלק מתהליך בדיקת הקוד - בין השאר בגלל הזמן הנדרש - ורנר מאמין שזו דרך מהירה לקבוע אם עליכם להשקיע בבדיקת זמן רב יותר, כמו גם אסטרטגיה שתעזור לצמצם. צמיחת צבר באגים.
4. היה שחקן קבוצתי
הקלישאה מקבלת משמעות חדשה בכל הקשור לבדיקת קוד. "קח את הזמן לבחון כי זה בסיס הקוד של כולם", אומר ורנר, הדוגל בתחושה של "בעלות קולקטיבית." אתה, בתור הסוקר, אמור לפעול להגנה על צבר הבאגים מפני הגדלה במטרה לתת צוות פחות עובד בקו.
פילאי משתמש ב- gifs לחגיגת יחסי ציבור מאושרים ומוכנים למיזוג חבריהם לקבוצה.
במקביל, צ'רלס לוקסון, מוביל טכנולוגי ב- Muse, מעודד את הסוקר להבין ולזכור את סדר העדיפויות של הצוות. עם מועדים ומחלוקות במהירות המתקרבים במהירות, לעיתים יצירת פריט מטלה עבור הצבר שמבטיח שיבוצעו בעתיד שיפורים והעלאת הערה על הקוד המדובר בינתיים היא עזרה ראשונה שאתה צריך כדי שמור על הצוות שלך מאושר.
לבסוף, לשאול את עצמך אם הקוד יהיה הגיוני למישהו שזה עתה הצטרף לקבוצה וקרא אותו במהלך השבועות הראשונים שלו יעזור לשמור על הקוד שלך קריא ומובן.
5. השתמש בתהליך למידה ושיתוף ידע
תהליך הסקירה נותן לכל המעורבים מקום לקבל תובנה רבה יותר על בסיס הקוד, שפות, מסגרות ושיטות עבודה מומלצות.
מאט ג'פרי, מוביל טק במוזה, מייעץ לבודק "להבין את השינויים מבחינה ארכיטקטונית. דרך אחת היא לקרוא שמות קבצים מאחר שהם עוזרים לתת הקשר. לדוגמא, אם אתה מסתכל על שינוי בשכבת הגישה לנתונים אתה יודע שאתה לא מתמודד עם היגיון עסקי או ממשק משתמש. "
אתה יכול להשתמש בתגובת יחסי ציבור ב- GitHub כדי לשתף תיעוד.
כשאתה לומד משינויי קוד, יש לך גם אפשרות לשתף ידע. "עדיף להסביר את דעתך ולגבות אותה בתיעוד", אומר לוקסון. הקישורים שאתה מספק לראיות תומכות ומאמרים אמינים לא רק עוזרים לסוקר ולכותב הקוד לחקור גישות שונות בזמן שהם מקבלים החלטה סופית, אלא גם מחזקים את הידע שלהם בתכנות.
כשאתה שומר על העצות האלה, זכור גם שהסקירה היא זמן לממש את כישורי העם שלך. "תן לאנשים את התועלת מהספק שהם חשבו על הגישה שלהם והצביעו על אפשרויות שונות תוך ניסיון לפזר את ההגנה", אומר רודר. "אני משאיר הערות לאורך כל הדרך והערה עוטפת - הנה מה נהדר, הנה מה שאפשר לשפר, הנה מה שצריך לשנות לפני שמתמזג."
בגישה מסוג זה, לא רק שתגן על בסיס הקוד שלך מפני חובות טכניים, איומי אבטחה ובאגים, אלא שתבנה גם את הצוות שלך.
