אחת הבעיות שאני נתקל בה רבות בתחום העבודה שלי, היא חוסר ההכרות וחוסר התקשורת בין גוף הפיתוח לבין גוף התשתיות. חוסר ההכרות הזו עולה בדרך כלל לארגונים הרבה כסף. הבעיה היא, שלמרות שלכאורה הפתרון לבעיה הוא פשוט, מהבחינה הארגונית, זו בעיה כמעט בלתי פתירה.
נתחיל מהשאלה "כמה שווה לארגון חיסכון של קרוב לשלושים אחוז בעלויות התפעול השוטפות של מערכות תכנה ארגוניות". התשובה שכל CFO יתן לך זה" "שלושים אחוז מעלויות התפעול זה המון כסף". והשאלה הבאה שלו תהיה, כמה זה עולה לי, והתשובה, "תוספת של 3-5 אחוז מעלויות הפיתוח, פחות חסכון של לפחות 10 אחוז ב QA". זה השלב שה CFO אומר בדרך כלל "אני רוצה את זה עכשיו ומייד".
הלוגיקה הפיננסית מאחורי ההתלהבות של ה CFO נובעת בעיקר מהעובדה הפשוטה, שבפרויקט טיפוסי, גוף הפיתוח משקיע, לצורך העניין, שנתיים בפיתוח מערכת תכנה. מגלגל אותה מעבר לגדר למחלקת התשתיות. ושם התשתיות סובל ממנה, לצורך העניין, עוד שמונה שנים. יחס יפה של 2 ל 8. ואל תתפסו אותי פה על שנה לפה או לשם, זה בממוצע נכון לרוב המערכות בסביבות הארגוניות.
אז איך זה מתקשר לנושא התקשורת וההכרות בין מחלקת הפיתוח (או הקבלן המפתח החיצוני) לבין מחלקת התפעול ? מקור הבעיה נובע בדיוק מזה, שלמפתחים אין בדרך כלל מושג ירוק מה זה סביבת ייצור, ולאנשי התשתיות אין בדרך כלל מושג ירוק על פיתוח תכנה. וכתוצאה מכך המפתחים, לא מכניסים לפרויקט, את הדרישות ה"לא פונקציונאליות", שאנשי התשתיות זקוקים להם, לצורך התפעול השוטף והיעיל של המערכות. ואילו אנשי התשתיות, לא יודעים אפילו להגדיר, בצורה שתובן על ידי המפתחים, מהם אותם דרישות "לא פונקצינאליות" שהם זקוקים להם כמו אויר לנשימה.
והסיבה שאני שם את כל נושא ה "לא פונקציונאלי" במרכאות, היא שלטעמי הדרישות האלה מאד מאד פונקציונאליות. מערכת תכנה ידידותית לצוות התשתיות, דורשת הרבה פחות "תשומת לב ניהולית", מאשר יישום שאינו ידידותי לסביבת התשתיות. ומאחר וכל "תשומת לב ניהולית" כזו, היא הוצאה כספית, זה נושא חשוב. כדאי אולי לציין בנקודה הזו שאני לא מדבר פה רק על הזמן של אנשי התשתיות. קחו בחשבון, שבזמן שמערכת התכנה מתעופפת לה בעליזות, כל משתמשי הארגון, המחוברים לאותה מערכת תכנה, בפועל מושבתים.
מה שאנשי התשתיות רוצים (וזו דרישה משותפת גם לאנשי ה QA וה Testing), זה לדעת כמה שיותר מוקדם, שמערכת התכנה הולכת להתעופף (או התעופפה), כך שיהיה להם מספיק זמן להגיב. אנשי התשתיות רוצים שזמן איתור התקלה שגרמה לבעיה, יהיה הכי מהר שאפשר. הם רוצים שהמערכת תחזור למצב עבודה כמה שיותר מהר. דרישה "לא פונקציונאלית" נוספת, היא שאם הבעיה אינה מוכרת, יאסף עליה מספיק מידע, כך שניתן יהיה להבין, ממה בדיוק היא קרתה, וכיצד למנוע ממנה לחזור שוב.
למערכת ההפעלה ישנם הרבה מימשקים מובנים, שמאפשרים למערכת התכנה, לדווח על מצב בריאותה, בצורה שהמידע יהיה זמין לאנשי התשתיות. יש מערכות Trace מובנות במערכת ההפעלה, שמאפשרות לאסוף 20,000 ארועים בשניה, בהעמסה של פחות משלוש אחוז CPU. יש כלי דיווח פעילות רציפים, בצורה של "מונים", שמאפשרים לנתח פעילות שוטפת וקווי מגמה, לפעילות המוגדרת על ידי המפתח, של מערכת התכנה על ציר הזמן. וגם לסנכרן אותם עם ארועים חיצוניים. יש מנגנוני התממשקות למערכות הדיווח השו"ב-יות של מערכת ההפעלה, אליה מתממשקים כל תוכנות ניהול התשתיות הארגוניות. יש מערכות דיווח שמציפות בעיות מיידית לצוות התשתיות. יש כלים המאפשרים להוציא את מצב מערכת התכנה ברגע ההתעופפות, כך שמחלקת הפיתוח, תוכל לנתח במדויק, באיזה שורה בקוד ארעה הבעיה. כל הדברים האלה מופיעים תחת נושא ראשי אחד, שאני קורא לו Instrumentation.
אבל אנשי הפיתוח לא יכניסו את כל הדברים "הלא פונקציונאליים" האלה למערכת התכנה שלהם, אם הם לא יוגדרו מראש, ובצורה ברורה, בדרישות המערכת. אז איך משחררים את הקשר הגורדי הזה ?
אז ישבתי והחלטתי לעשות מעשה. הכנתי סדנה מרוכזת בת יום אחד, שנועדה ל"מגדירי דרישות". דהינו, כל אלה שיש להם יד ורגל בהגדרת דרישות המפרט של מערכת התכנה. ואני מדבר על קהל של מנתחי מערכות, ארכיטקטים, מנהלי פיתוח, מפתחים בכירים, מנהלי מחלקות בארגוני תשתית, מנהלי מחלקות QA, אנשי QA בכירים, נציגי לקוח בבתי תכנה, וכל מי שרוצה שמערכת התכנה המוזמנת, תהיה "ידידותית" לסביבת התשתיות (ולסביבת ה QA).
בסדנה הזו אני מסביר על כל יכולות ה Instrumentation של מערכת ההפעלה, ומדגים ומסביר כל אחת מהן, עם כלי המערכת הקשורים אליו, בצורה שתאפשר למשתתף הסדנה לבנות ממנה דרישה מושכלת ל Feature במערכת התכנה שאותה הוא מגדיר או במערכת התכנה הקיימת שאותה הוא רוצה לשפר. כל הקונספט שאני קורא לו שו"ב אפליקטיבי מוסבר בסדנה הזו. מי שמעוניין, יוכל למצוא פרטים נוספים באתר החדש של חברת האם שלי. הסילבוס של הסדנה נמצא כאן, יש כבר תאריך לסדנה הקרובה. ואם אתם מעונינים בפרטים נוספים, אז גשו בבקשה לכאן.
אשמח לקבל משוב מקוראי הבלוג שלי, גם על הרעיון, וגם על הנושאים שהייתם רוצים להוסיף ליום הזה.
עדכנו את האתר של חברת האם שלי, קודם כל עברנו מהתבנית ההיסטורית של Front Page לתבנית יותר מעודכנת של Expression Web 4. השקענו קצת באנגלית (האתר הישן היה עברי בלבד). מחקנו המון דפים שלא נראו לנו חשובים יותר. ומיקדנו את שאר הדפים בשרותים ובמוצרים העיקריים שלנו. חסר לנו עוד להוסיף כמה תמונות פה ושם ואולי גם דברים אחרים. כמי שריכז את הנושא (וגם נאלץ הדריך את הפועלים השחורים בנפלאות ה Expression Web 4, שלא היה מוכר להם), אני אשמח מאד לקבל מקוראי הבלוג שלי משוב ורעיונות לשיפורים. כמעט שכחתי, הכתובת היא www.idag.co.il.
לא הייתי במפגש הראשון והשני, לא יצא לי, חבל. אבל מצד שני למפגש הזה הצלחתי להגיע למרות הפקק המוגזם שהיה באילון. זה די מצחיק שדווקא בשעות שכולם יוצאים מתל אביב, אי אפשר להגיע למרכז תל אביב במהירות. אה, כן המפגש היה הפעם במשרדי CheckPoint, ממש ליד תחנת רכבת השלום בתל אביב. במחשבה שניה, אולי הייתי צריך להשאיר את האוטו בהרצליה ולהגיע ברכבת, היה עולה לי פחות, גם דלק וגם הייתי יכול לעבוד קצת על המחשב בדרך.
כללי המשחק של הקבוצה לא מסובכים אבל יש בהם קצת אתגר. החלק הראשון מוקדש להרצאה או משהו כזה, ואילו החלק השני הוא עם השם המפחיד Coding Dojo, שמה שמסתתר מאחוריו שה עבודה בקבוצות מתחלפות על בעיית קוד, כך שבתהליך יש גם הפריה הדדית וגם לימוד. נשמע מפחיד, כי אני מאלה שכותבים תמיד קוד מכוער, אבל מהסוג שעובד שנים ללא תחזוקה. אבל מצד שני אין דרך יותר טובה ללמוד את אומנות כתיבת הקוד הנקי.
לאחר מילות הפתיחה של מנחה הקבוצה אורי לביא עלה על הבמה אורי ה CTO של OutBrain ובאמצעות מצגת שכתובה ה Flash (מרענן לגלות שיש אנשים שלא משתמשים ב Power Point), דיבר על "יש עם מי לדבר ?" והציג את www.iltechtalks.org.il, שבעקרון מיועד לקשר בין אנשי מקצוע שיש להם שאלות, לבין מומחים מהתעשיה שיש להם את הידע.
אחרין עלה לבמה ליאור פרידמן והעביר מצגת על Writting better code (נשמע מרשים באנגלית) וכן, הוא דווקא השתמש ב PowerPoint. ליאור הזהיר שהוא הולך רק לתת טעימות ושהוא לא יוכל לכסות הכל, וזה היה ממש טוב בשבילי, כי זה בדיוק מה שרציתי. ליאור התחיל מהמוטיבציה, למה זה חשוב. דיבר על הדרישות התיאורטיות מקוד טוב (כל המילים שמסתימים ב – bility). ומשם עבר לרשימה מצומצמת יותר. התכנון האידאלי מסתבר הוא תלוי הקשר, ומאחר וזה אומנות, אין תכנון אחד מושלם.
אחר כך הוא ירד לפרטים ודיבר על כתיבת מתודות קטנות, בחירת שמות טובה, שימוש במעט פרמטרים, מיקוד בדבר אחד רבל לכסות אותו בצורה מלאה, רמת אבסטרקציה אחת, בלי תופעות לוואי (לך תתרגם Side effecys) וכו'. לא שתמיד אפשר לעשות את זה, אבל לפחות ניתן לנסות לשאוף לזה. לאחר מכן ליאור עבר לדוגמא מעשית של קוד ספגטי מפחיד, שאותו הוא שיפר לאט לאט, עד שהגיע למשהו שהיה הכי קרוב לעקרונות של קוד נקי.
לאורך כל הקטע הזה היתה השתתפות ערה מהקהל. היתה המון התלהבות והרבה רגשות. לומר את האמת מאד שמחתי על הנקודה הזו, כי הנושא של כתיבת קוד מקצועי הוא נושא מאד אמוציונאלי. כבר אמרתי באיזה שהוא מקום, שמי ש"קודו אומנותו" לא יכול שלא להיות אמוציונאלי בנושא הזה, כי כשהוא רואה קוד לא נקי, זה ממש כואב לו בבטן. כמובן שהיתה גלישה בלוחות הזמנים,אבל היה מעניין בלי כל קשר. ליאור העביר את הנושא בצורה מעולה (כרגיל) וניהל היטב את הקהל הפעיל והמגיב.
בשלב הזה היתה הפסקה והלכנו כולם ל Dojo, שזה היה מבחינתי תערובת בלתי אפשרית של Pair Programming כאשר עשרים איש נמצאים לך מאחורי הכתף ומעירים הערות. מאחר וכל פרק זמן, הזוג על המוקד מתחלף ועובר לאחרי הכתף של הזוג התורן הבא, יש לכולם סיכוי טוב, גם לתת ביקורת בונה, וגם לקבל ביקורת בונה.
אני עברתי בין הקבוצות והקשבתי ודיברתי עם המון אנשים שהרבה זמן לא פגשתי אותם. הסתבר לי שפיספסתי ארוע של Alt.Net, וזה חבל כי אני מאד אוהב להשתתף בארועי Alt.Net. חלק מאלה שפגשתי קיטרו על זה שכבר מזמן לא כתבתי בבלוג, אז הנה אני כותב.
אם אתם רואים בכתיבת קוד תחום מקצועי שבו עליכם להתמקצע ולהצטיין, אל תחמיצו את המפגשים של הקבוצה. ניתן בדרך כלל למצוא עליהם פרטים בקבוצת ה LinkedIn שלה או בבלוג של אורי. את השקפים של המצגת (למרות שהם לא משקפים את החוויה של הנוכחות האישית) ניתן למצוא כאן.