למה אני אוהב Code Reviews?

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

מקור: Pixabay

מאת דוד בהט, Expert software development engineer, SAP

זה היה עוד Code review, כמו רבים אחרים, אך פתאום מצאתי את עצמי שואל שאלה שעד כה נראתה לי די בסיסית: “למה ה-members במחלקה הזאת לא private?”. התשובה שקיבלתי תפסה אותי לא מוכן: “למה שהם יהיו private?”.

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

– “יש סיבה שאתה מעדיף לחשוף את ה-members במקום לייצר properties?”, שאלתי.
– “בשביל מה צריך פה properties?”, הוא ענה.

עוד פעם הוא תפס אותי לא מוכן. עבר זמן רב מאז ששאלתי את עצמי לגבי היתרונות והחסרונות של כלל הברזל, לפיו “לא תחשוף members”. זאת הייתה בפירוש קריאת תיגר שהכריחה אותי לאבק את קורי העכביש במוח ולתקוף סיבה אחר סיבה:

“אתה לא תוכל להוסיף בעתיד קוד כמו בדיקות תקינות”, ניסיתי להתקיל.
– “המחלקה הזאת היא POJO בלבד. אתה יודע שלא יהיו פה בדיקות תקינות”, הוא ענה.

“למה זה כל כך מפריע לי?”

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

– “מה לגבי ירושה? מחר משהו ירצה להרחיב את המחלקה והוא תקוע עם ה-members, שהרי לא ניתן לדרוס אותם בירושה”.
– “אין שום בעיה”, הוא אמר, ומהר הוסיף למחלקה את המילה sealed, המבטיחה שלא ניתן לבצע ירושה.

– “אבל למה אתה רוצה לייצר הגבלה כזאת? כמות הקוד במקרה של members ושל auto-properties כמעט זהה, אבל עם properties תוכל גם להעיף את ההגבלה, להקטין את הצמידות בין האובייקט הזה לאחרים, לשנות טיפוסים של ה-members בלי לגעת בכל מי שמשתמש במחלקה, ו..”, פתאום הבנתי שבשלב זה כבר מזמן לא דיברנו על ה-code review הספציפי, אלא עברנו לדיון ברומו של עולם לגבי נחיצותם של properties.

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

אירוע גיקטיים 2018

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

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

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

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

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

כתב אורח

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

הגב

19 תגובות על "למה אני אוהב Code Reviews?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
סידור לפי:   חדש | ישן | הכי מדורגים
Wtf
Guest

אם זה קוד סי שארפ זה poco
לא
Pojo =)

BakaNano
Guest

כתבה מגניבה, נושא חשוב, אבל ספציפית לגבי העיניין עם הproperties: יש עיניין של אחידות בקוד, ברוב המקרים עדיף properties על public members מהסיבות שכבר ציינת, במקרה הספציפי הזה זה אולי לא משנה, אבל עדיין עדיף לשים properties כדי לייצר אחידות, כדי שלא כל מי שיכנס למחלקה הזו ישאל את עצמו “היי, רגע, למה דווקא פה זה members?”

David Bahat
Guest

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

BakaNano
Guest

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

that said, זה נושא מעניין, צריך לדבר על דברים שאנחנו עושים כל הזמן כדי לוודא שאנחנו לא עושים דברים סתם, אבל אם קבעת קונבנציה צריך לשמור עליה וקוד שלא שומר עליה לא צריך לעבור code review.

ארכיטקט vs מהנדס
Guest
ארכיטקט vs מהנדס

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

אור
Guest

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

יונתן
Guest

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

quick&dirty is the new king
Guest
quick&dirty is the new king

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

משה כגן
Guest

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

JustAbotherType
Guest

תודה שהמחשת לי למה אין סיבה ללכת לכנס הזה.

כפכף למצח
Guest

אתה סתם חסר בטחון- תכנות זה אמנות – לא מדע מדוייק, איש איש וסגנונו
יש לבחור מזל שהוא לא עשה review לקוד שלי (-:

gitBucket
Guest
כל מפתח כותב קוד לפי האישיות שלו. הזרקנים כותבים קוד מרושל והפרפקציוניסטים עם ה-OCD שלהם חוגגים עם תוספות שלא עושות כלום. כך או כך, קשה להגיד מה נכון – זה תלוי בקוד ובמורכבות שלו, במספר המפתחים שיעבדו איתו ובקריטיות הפרוייקט. מה שכן, בתור מי שאוהב סדר וניקיון, קשה לי עם המשפטים האלה: “למה צריך את זה?” שאלות כאלה הן עלה תאנה עבור מתכנת רשלן (ללא קשר לאלה שבכתבה) כדי לכתוב קוד עם פחות הגנות. יש קונבנציה כללית שיש לקבל אותה כקבוצת פיתוח ו-once היא התקבלה צריך ליישר איתה קו. כל מתכנת מכיר את החריקת שיניים כשהוא מקבל reject על משהו… Read more »
יאיר
Guest

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

Class של 5000 שורות
Guest
Class של 5000 שורות

אבל מספיקים הרבה יותר…
ככל שאני מזדקן אני מבין שעדיף לעשות פרוטוטייפ מהיר ומלוכלך שעובד ורק בשלב יותר מאוחר לפרק אותו לתוך Design ולנקות מאשר לקודד תוך התחשבות באסטטיקה של הקוד
לא מזמן כתבתי class של 5000 שורות תוך שבועיים, פשוט כי בער לי לראות תוצאה, מיותר לציין שהיו מלא באגים והדיבוג נהיה נורא מסורבל – אז קיצצתי את הקוד לחמש מחלקות של 1000 שורות כל אחת לפי חלוקה שנראתה לי הגיונית מבחינת תוכן
הדיזיין נראה בסוף קצת מכוער מאולץ ולא סטנדרטי אבל הקוד רץ יופי (-:

gitBucket
Guest

בגדול אני מסכים.
אם קורה מצב בו צריך תוצאות זריז כדי לדעת איך להתקדם הלאה, fast & dirty תופס. נקודה.

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

הצופה
Guest

“פתאום הבנתי שבשלב זה…”

בשלב הזה נראה לי שהיית צריך להגיד לו להשתמש ב struct.

dotnetperls.com/struct

מתן
Guest

האתר שהבאת מפוצץ בפרסומות.
ממליץ לאף אחד לא להכנס

דניאל
Guest

בלי לבטל את הפואנטה הלגיטימית של הכתבה, מקרה הבוחן בה לא רלוונטי לדעתי. auto implemented properties מוסיפות המון גמישות לקוד וכמעט בחינם; הן נכתבות באותה הקלות והמהירות כמו שדות member פשוטים (דרך snippets) ולא מנפחות את הקוד. יש מקרי קיצון שמצדיקים שימוש ב-public fields בלבד (כשמאוד חשוב לחסוך הפנייה אחת מ-setter או getter), אבל פה זה לא היה המקרה.

אני
Guest
wpDiscuz

תגיות לכתבה: