Your SlideShare is downloading. ×
  • Like
Avi Etzioni on Code Review @Outbrain
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Avi Etzioni on Code Review @Outbrain

  • 126 views
Published

Avi Etzioni talks about the importance of code-review when writing quality code. This tech-talk was given at Outbrain Israel - 31/10/2013. …

Avi Etzioni talks about the importance of code-review when writing quality code. This tech-talk was given at Outbrain Israel - 31/10/2013.

You're also welcome to visit my blog: http://avietzioni.blogspot.co.il/

This is the slides for the presentation on Youtube: http://youtu.be/NeV1tP1IfoM

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
126
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • אז הסיבה שבחרתי לעשות את ההרצאה הזו היא התשוקה שלי לאיכות קודאני מאמין שכתיבה של קוד איכותי, עם סטנדרטים קבועים, דיזיין בריא היא חשובה לכל פרוייקט ובעיקר לפרוייקט בסדר גודל שלנו.אני מניח שלרוב האנשים אין צורך להסביר איך קוד איכותי מקצר תהליכי פיתוח, מאפשר להכניס מישהו חדש לעניינים מהר יותר ומונע באגים.חלק גדול ממה שחשוב באיכות קוד ניתן, לדעתי, למצוא ולשפר בזמן קוד ריויו
  • בהכנה למצגת נזכרתי בתמונה המשעשעת הזאת שראיתי פעם.ההרצאה של היום לא תהיה כבדה, אני לא בא להטיף פה לאף אחד. רק בתקווה אצליח לשכנע גם אתכם כמה שקוד ריוויו זה דבר חשוב לשמירה על איכות הקוד ולייעול תהליכי פיתוח.
  • אנחנו מופתעים כשבשלט חוצות לא עשו reviewלמה אנחנו מופתעים כשאנחנו נדרשים להציג את הקוד שלנו?
  • אנחנו מופתעים כשבשלט חוצות לא עשו reviewלמה אנחנו מופתעים כשאנחנו נדרשים להציג את הקוד שלנו?
  • אז זאת הייתה רק הקדמההחלק הראשון ידבר על קוד ריוויו בכללי – יתרונות והאני מאמין שליבחלק השני נדבר על תרבות של קוד ריוויו תוך שימוש בריוויו בורד
  • אז לפני שאנחנו מדברים על איך עושים קוד ריוויו – בואו נתחיל בלמה?
  • ביום הראשון לעבודה קיבלתי את הספר The lean startupהמטרה באג'ייל היא ללמוד ולהשתפר כל הזמן – continuous improvement
  • כשרק הכותרת מופיעה - בואו ננסה למפות את הפידבקים החשובים בתהליך הפיתוח של פיצ'ראחרי שהצגנו את חלוקת הפידבקים - בחלקים הקריטיים אנחנו רוצים התערבות אנושית ולא מחשב שיעשה דיזיין והפקת לקחיםהמחשב לרוב מגלה לנו סימפטומים. אנשים מגלים לנו בעיותהאם שלב כתיבת הקוד לא מספיק חשוב בשביל לקבל מעט פידבק אנושי?
  • Functional – Problems in the execution layerNon-functional – Especially things that will affect the maintainability of the code laterFalse-positive – The reviewer said something to be a defect and later turned out it wasn’t
  • אוניברסיטת הלסינקי בדקה את פיזור הדפקטים שמתגלים במהלך ריוויו. השוו תוכניתנים מנוסים לתוכניתנים לא מנוסים – פיזור דומה מאוד.
  • Structure – repeated code / Code that should be in a different place / Solution arrangement. It’s 52% Solution approach (different algorithm; use external lib, etc…) and 48% for organization (structure of the code; classes not in place, split method, etc…)Documentation – comments in code; Api documentation; Names of methods/variables/classesVisual representation – tabs/spaces
  • Pair programming – Depends on the seniority and chemistry of codersWe need to remember that unit-tests are need to be maintained and debugged as well.Code review meetings might take too long and people tend to loose consentration
  • הידיעה שהולכים להסתכל על הקוד שלך גורמת לך לעשות מעבר נוסף ולהשקיע בקודמי שעוד לא מבין מה קורה יבוא בצורה יותר ביקורתית )בגלל זה אני פחות אוהב ריוויו אחד על אחד(ככל שנעלה על באגים או על מבנה קוד בעייתי לתחזוקה מוקדם יותר, כך יהיה כל יותר לשנות בהמשך. מגינים על מי שיקרא את הקוד בהמשך, שזה הרבה פעמים אני העתידיתמיד יש מישהו שיוכל ללמד אותך משהו חדשעל ידי פירסום של שיטות העבודה שלך, אחרים יוכלו ללמוד בעצמם דרכים טובות יותר לבצע דברים ולשפר את עצמם
  • כולנו צריכים לקרוא קוד בעבודה שלנו כשנכנסים לפיצ'ר חדשגם מהתבוננות בקוד של מישהו אחר אפשר ללמוד טכנולוגיות/שיטות/צורות חדשות לעשות דבריםלהבין השפעה של העבודה שלך על המערכת/להכנס לרכיבים חדשים מהר )תורנות ביפר(/הגישה ההוליסטיתכולנו בעלי מטרה משותפת וההצלחה של הצוות היא ההצלחה של כולם )לא לזרוק אחריות(כולנו קיטרנו על קוד מכוער, "לא ככה עושים את זה"
  • כפי שאמרו – הקוד ריוויו משפר יכולות קריאה והבנה של קוד ועוזר ללמוד על דרכים שונות לעשות דבריםכולם יודעים הכל. קל יותר להוסיף פיצ'רים ולפתור באגים בטריטוריות חדשות; פחות תלות בבנאדם ספציפי )אין ג'וב סקיוריטי(גם אם זה עובד חדש וגם אם זה עובד שעבר מצוות אחרהרבה אנשים בדקו את הקוד, מוריד כמויות באגים, מעלה את יכולות התחזוקה של המוצר וכו'מעודד דיון על דברים, מציף שאלות ובעיות – חלק ממעגל הפידבק
  • בדר"כ בשלב הזה של השיחה מתחילים ה"אבלים" שאנשים אוהבים לתת לי אז אני אנסה להפריך כמה מהנפוצים שבהם.
  • דיזיין לא לוקח זמן? מה לגבי בהייה בגרפיטוס – גם אלו כלים שלוקחים זמן. אבל אנחנו מרגישים יותר בנח לגבי הזמן הזה - שבסופו של דבר מקצר תהליכיםמה לגבי יוניט-טסטס? על כל שורה של קוד אנחנו כותבים הרבה יותר קוד נוסף שגם דורש תחזוקהיהיה על זה שקףלמעשה חוסכים זמן עתידי
  • בסעיף 2 – אותו מחקר של אוניברסיטת הלסינקי
  • The study showed that the rate between senior and junior programmers was pretty much the same
  • אז בואו נעבור לקצת קווים כלליים לגבי איך עושים קוד ריוויו
  • קשה להתמודד עם כמויות של קוד ללא הקשר וללא IDEחלק מהאנשים יראו כמויות של קוד וירגישו שהם לא מבינים מה הולך. עדיף למנוע מהםגם מי שכבר נכנס לקוד ייתכן ויתייאש תוך כדי כי זה לוקח הרבה זמן. עדיף לכוון לריוויו שניתן לסיים ב-5-10 דקותלדוגמא – צד שרת, צד לקוח. לעבוד בצעדיo קטנים ולפרסם כל פעם שינוי קטן בלבד. שינויים מסוימים יכולים ללכת לאנשים מסוימים
  • לא הכל ברור מראש – תן הסבר ראשוני ברור והרחב על דברים שעשויים להיות לא ברוריםציון של טסטים עוזר לקוראים להרגיש בנוח יותר לאשר את הריוויולפעמים יעלו הערות של "כדאי לעשות ככה" "תתקן פה... תתקן שם". אם כתבת מראש שזה בתוכניות שלך, זה יחסוך דיון מיותר.
  • אם יש סטנדרט – חשוב ללכת איתו גם אם זה לא מה שאתה אוהבאם אין סטנדרט זה עדיין לא אומר שהסטנדרט שלך הוא הנכון.שמור על נימה מיעצת ולא שיפוטיתלא על כל דבר שווה להתעקש.דוגמאת ניטפיקינג
  • שגיאות כתיב – קל לאתר, לא מעליבהאם יש מצב שבשורה הזאת והזאת יהיה אקספשןשמות משתנים לא מייצגים? מתודה באותיות פסקל?
  • שגיאות כתיב – קל לאתר, לא מעליבהאם יש מצב שבשורה הזאת והזאת יהיה אקספשןשמות משתנים לא מייצגים? מתודה באותיות פסקל?
  • דברים דומים שאולי ניתן לאחדהאם הקלאס הזה אמור להיות מוגדר בפרוייקט הזה? או שזה יצור צימוד בעייתי בעתיד? מה עם הבינים של ספרינג?

Transcript

  • 1. Code Quality: Code Review { By Avi Etzioni; } Available on Youtube: http://youtu.be/NeV1tP1IfoM
  • 2. Code Quality = #WTF/Min
  • 3. Review – not only for code Students Politicians Books
  • 4. If only someone reviewed…
  • 5. Agenda  Part 1 – Code Review – Who needs it? Feedback  Some numbers  Why should I seek this feedback?  Why should I review others work?  Ok, but…   Part 2 – Guidelines for creating and reviewing
  • 6. Part 1 Code Review – Who needs it?
  • 7. Feedback is all around us Design Problem IDE Automatic Tests Build/Integrati on Symptom Monitor Take in
  • 8. Some numbers…
  • 9. Type of defects found in review  Functional  Non-functional / Maintainability issues  False positive
  • 10. Distribution of defects 7% 21% Maintainability Functional 71% False positive
  • 11. Maintainability Distribution 10% Documentation 35% Structure 55% Visual Representation
  • 12. Defect Reduction • Pair Programming: 15%-50% • Unit-Tests: 30%-60%: • Increase in development time: 20%-30% • Does not take into consideration bugs found during the writing of the tests • Code review meeting: 45%-50% • Asynchronous code-review: 60-65%
  • 13. Why should I seek this feedback? • Enforces better code inspection • Unbiased set of eyes • Find your problems sooner than later • Learn new stuff • Teach the others
  • 14. Why should I give this feedback? • Improve code reading skills • Learn new stuff • Better understanding of the code • Common goal • Let your voice be heard
  • 15. What about the organization • More capable employees • Knowledge sharing • Training for new team members • Better quality of the product • DISCUSSION
  • 16. Ok, but…
  • 17. Ok, but… It takes too much time • What about Design? Graphitus? Take in? • Unit-tests • Who checks them? • It’s better to favor small reviews • Maintainability issues can make adding new functionality 28% slower and fixing errors 36% slower * *Bandi, Vaishnavi, Turk: Predicting Maintenance Performance Using OO Design Complexity metrics
  • 18. Ok, but… I’m not familiar with the code
  • 19. Ok, but… I’m not familiar with the code
  • 20. Ok, but… It’s too subjective • That’s true, but… • Research shows 82% agreement • Add more reviewers • You don’t have to agree (just be nice about it)
  • 21. Ok, but… It’s a minor-change
  • 22. Ok, but… I’m a Rockstar 7% 21% Maintainability Functional 71% False positive Remember This??
  • 23. Part 2 General Guide Lines
  • 24. Favor small reviews • Reviewing a lot of code is a lot to process • Might intimidate people from starting the review • Those who start, will probably not finish • Think of logical ways to split the reviews
  • 25. Explain yourself • What have you done? • High-level explanation • Detailed explanation about non-trivial changes • Testing Done: • mvn [install ; test ; test –P integration]? • Started the service? • Ran APT? • Simulated tests? • Next Steps
  • 26. Tie your ego to quality… Not to your code • Comply with standards … But remember that style is a matter of taste • Don’t criticize - advise • Choose your battles • Be polite • Maybe I don’t understand everything, but… • I would prefer... • Nitpicking: …
  • 27. And if you have nothing to say… • Ship it! • A good word never hurt anyone 
  • 28. What to look for???
  • 29. Start with searching for the obvious and easy wins • Typos • Commented code • Wrong/missing description • Trivial exceptions – NPE, OutOfBounds… • Coding conventions
  • 30. And continue with the not so obvious • Similar (but not exactly duplicated) code • Project structure • Affected components / Tests that might break • Hidden pitfalls / Bugs • Security • ADVANCED LEVEL: patch the code and run it!
  • 31. How to start?
  • 32. Thank you! aetzioni@outbrain.com Twitter: @AviEtzioni