כתבנו בכנסת מדווח מישיבתה הראשונה של שדולת הטכנולוגיה שזה מכבר הוקמה. מסביב לשולחן הדיונים יושבים רן תבורי, ישי סמית', ארז מזור, גילי נחום ואיתי ממן.- על קרש החיתוך: Code commits as conversation
- הכלי המשמש כ-Code Repo ואופן השימוש בו מכתיב אתן התקשורת בין אנשים.
- כמות המידע המועבר ב-commit מאוד תלויה בחברה, הכול הולך - החל תיאור לאקוני אל הקוד ועד רומן רחב יריעה בהמשכים
- יש כל כך הרבה ערוצי תקשורת (צ'אט, אימייל, קומיטים, שיחות מסדרון, פגישות) - לפעמים קשה לבחור באיזה ערוץ להשקיע את תשומת הלב (יש כאלה הקוראים לזה Decision Overload, ויש גם פתרונות)
- בגוגל כל קומיט עובר ריוויו, בלי הנחות (Code conventions, module, feature) - שלושה אישורים לכל קומיט (אבל לא באמת צריכים שלושה אנשים …)
- קומיטים גדולים הם בעיתיים. מצד שני, כל דבר גדול מדי הוא בעייתי. בכל מקרה, האפקטיביות של הריוויו יורדת ביחס ישר למספר שורות הקוד.
- Eclipse יודע לשמור את הקוד - אחרי שהוא מפרמט אותו לפורמט הבית
- אפשר ללמוד הרבה מכל קומיט ודיונים בעקבותיו יכולים להיות מאוד מפרים לכל הנוגעים בדבר.
- האם קוד ריוויו לכל החברים בצוות פוגע בפרודקטיביות ? כנראה שכן, אבל יותר חשוב לקרוא את ההערות לקומיט מאשר את הקוד עצמו (בשביל זה, כמובן, צריך להקפיד על הערות איכותיות...)
- ובכלל, איפה האיזון בין כמות הקוד ריוויו שמתכנתת עושה לכמות הקוד שהיא כותבת?
- ומה עם Pair Programming ? צריך ריוויו או לא?
- ב-IBM אי אפשר לעשות קומיט בלי להגיד לאיזה משימה שייך הקומיט הזה.
קצרים:
- במשפט בין גוגל לאורקל - אורקל לא ניצחה (תודו שאתם שמחים, תודו …). אורקל תובעים עכשיו את לודסיס (פטנט טרול ידוע לשמצה) בשביל לקבל קצת אהבה מהעולם. שיהיה בהצלחה.
אירועים:
הקובץ נמצא כאן
האזנה נעימה ותודה רבה ליותם אורן על העזרה!