אורי לביא על בניית צוותים מצליחים

במסגרת ה-TechTalks ב-Outbrain הגיע היום אורי לביא מ-PicScout להסביר את עמדתו על אומנות פיתוח התוכנה, כיצד לטפח צוותים וכיצד לבנות צוותים מצליחים.

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

מה לדעתכם מחזור החיים של מהנדס תוכנה?

(עם או בלי פיצה...?)

טענה: התעשייה מתבגרת (לטובה) יש יותר מפתחים מבוגרים שאינם מנהלים בהכרח.

אנשים נוגעים בקוד בד"כ כ-10 שנים.

המחזור: למידה של שנה שנתיים, עבודה במה שלמדתי, עבודה חדשה בתחום דומה למקום הקודם, העמקה בנסיון, עבודה חדשה -- וחוזר חלילה. אורי טוען שיצא לו לראיין בין 200 ל-400 מתוך 500 ל-800 קורות חיים (הוא כבר לא סופר) ונדמה לו שהמחזור הזה תופס לפחות ב-75% מהמקרים. והוא טוען שזה מחזיק בערך 10 שנים. באלגוריתמים למשל הוא טוען שנשרפים באותו הנושא באותה החברה תוך שנה-שנתיים.

בתור חברה מצויינת יש לחברה צורך ליצור סביבה שמאפשרת למפתח להצליח.

software engineer vs. developer vs. coder

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

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

הטענה שיש 100% מאמץ ו-0% אפקטיביות. (הוצג סרטון bad code של uncle bob).

מה צריך לדעת? כלים כלים כלים -- לכל דבר צריך להכיר כלים שונים ופרדיגמות שונות:

IDE ולשלוט בו, טכנולוגיה של שפת התכנות, פרדיגמות שונות של שפות תכנות, אנליזה סטטית של קוד, ארכיטקטורה, בדיקות שונות למיניהן (יחידה, קופסה שחורה, קבלה, לקוח, וכו'...) על כל הכלים שלהן, להכיר HTTP וכלים לניתוח ולפיתוח, מה זה WEB, services, פלטפורמות שונות, מערכות הפעלה שונות, mobile, מסדי נתונים sql ו- nosql, להבין בניתוב ובקרה, אבטחה, continuous deployement, continuous integration ועוד ועוד... -- זה מה שמהנדס תוכנה צריך. זה לא מה שלומדים בלימודים בהכרח ובוודאי לא בהיקף הזה. מי שלא לומד לימודים אקדמיים חסר לו מספיק כלים להיות מהנדס תוכנה. ללמוד לתכנת בלבד זה לא מספיק. מהנדס נדרש ליותר יכולת בקבלת החלטות ובהכרות של כלים ותחומים רבים יותר.

מה לומדים?

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

צריך לצעוד בצעדים קטנים (baby steps) וצריך לחבק ולקבל שינויים. הכרחי להיות נלהבים.

הוצג קטע של Miyamoto Musashi שאומר שצריך ללמוד כל הזמן ולשקול יתרונות וחסרונות וכו'. הוזכר הספר The book of five rings.

מה עושה המפתח?

להתאמן -- ולהתאמן הרבה וכמה שיותר זה, לפי אורי להב, מה שמבטיח שלא תהיה שחיקה. יש להכיר מעבר -- וזה באחריותנו האישית.

לקרוא ספרים!

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

מה עושה החברה? לדאוג שיהיה כל זה וללמד את המפתחים את כל הנדרש לצורך זה:
להיות קנאים למערכת ה-version control.

מה ה-layout?

ניהול גרסאות.

מדיניות לכל check in -- בדיקות קוד, בדיקות יחידה, אנליזה סטטית וכו', כתיבת הערות ב-commit, לחבר למשימות ולבאגים שקשורים -- קישור למערכות הניהול שלהם.

automatic build system

unit testing

Test Driven Development

Refactoring

code reviews: peer reviews, team reviews -- מעבר למה שעושים ב-commit.

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

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

טיפול בחורים בידע, technical debts, איך להשלים חוסרי ידע.

Tree Model -- מפגשים חינוכיים של שעתיים-שלוש פעם בשבועיים. מפתח נבחר להציג טכנולוגיה חדשה או POC. הוא מקבל חצי מהזמן שדרוש לזה מהחברה וחצי מהזמן על חשבונו.

לקרוא ספרים!

לעשות book reviews.

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

אקוסיסטם: פירמידה הפוכה: לקוחות רבים למעלה, מפתחים אח"כ ולמטה מעט מנהלים. (הפוך מהפירמידה הרגילה)

visibility -- ההפך מ-"יהיה בסדר" ו-"עזוב" ו-"היתה בעיה ברשת..." ו-"זה לא עובד" ו-"ככה צריך לעשות את זה"... -- התבטאויות כאלה מסרסות אפשרות לשקול יתרונות וחסרונות.

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

A Day at Work --

כמה זמן אפקטיבי יש באמת ביום עבודה?

קפה: 15 דקות

שיחות חולין: 15 דקות

דוא"ל: 30 דקות

קפה: 15 דקות

שקט! עובדים: 45 דקות

דיון מה אוכלים: 30 דקות

ארוחת צהריים: שעה

קפה: 15 דקות

דוא"ל: 15 דקות

שיחות חולים ו-social media: 15 דקות

עבודה: שעתיים

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

צריך להיות מעורב ומשמעת!!

חוק הסחת הדעת: 15 דקות לשלווה. צריך זמן שנדרש לצאת מהסחת דעת ולהכנס לעשייה.

לתת הערכות זמנים, לנתח, להשתפר.

ישיבות קצרות ויעילות.

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

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

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

היה מעניין.

השיחה הוסרטה. אני מקווה שאזכור לקשר לסרטון לכשיהיה לי קישור.