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

על קרש החיתוך: Code commits as conversation

הכלי המשמש כ-Code Repo ואופן השימוש בו מכתיב אתן התקשורת בין אנשים.

כמות המידע המועבר ב-commit מאוד תלויה בחברה, הכול הולך - החל תיאור לאקוני אל הקוד ועד רומן רחב יריעה בהמשכים

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

בגוגל כל קומיט עובר ריוויו, בלי הנחות (Code conventions, module, feature) - שלושה אישורים לכל קומיט (אבל לא באמת צריכים שלושה אנשים …)

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

מתי עושים ריוויו, לפני שהקוד נכנס לעץ - או אחריו?

Eclipse יודע לשמור את הקוד - אחרי שהוא מפרמט אותו לפורמט הבית

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

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

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

ומה עם Pair Programming ? צריך ריוויו או לא?

ב-IBM אי אפשר לעשות קומיט בלי להגיד לאיזה משימה שייך הקומיט הזה.

הזמן עושה את שלו - קוד הבסיס ששונה בקוד ריוויו יכול להשתנות.

רוצים ללמוד עוד על קוד ריוויו טוב? יש איפה.

קצרים:

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

חייל בחופשה (בן לנג) עשה מצווה. אנחנו על המפה!

אירועים:

באוגוסט מתקיים "אוגוסט פינגווין". תבואו.

רוצים ללמוד Node.js ו-CoffeScript?. בפעם הבאה תירשמו בזמן.

IEEE ערכו כנס בישראל. מעניין.

הקובץ נמצא כאן

האזנה נעימה ותודה רבה ליותם אורן על העזרה!