מעבר גירסא של מערכת פיתוח הוא תהליך ארגוני לא פשוט. זה אף פעם לא מסתיים רק בהתקנה. להלן רשימה ממש חלקית של נושאים לטיפול: הסבת כל ה Solutions למערכת החדשה, תיקון הטעויות החדשות שהיו קבורות שנים בקוד ומתגלות בגלל שהכלי החדש מאתר אותם, עדכון תהליך ה Build, בדיקות QA לתוצרים החדשים כדי לוודא שהכל עובד כמו קודם, עדכונים נדרשים במערכת ה Source control ועוד נושאי טיפול רבים.

בדרך כלל ברעש ובמהומה של המעבר, יש נטיה לשכוח פרט מאד חשוב, והוא להדריך את הצוות על המערכת החדשה. כן, אני יודע מה קופץ לכם בראש,. אני מכיר את Visual Studio עוד מגירסא 6, אז למה אני צריך לבזבז את הזמן שלי בקורס על משהו שאני יודע כל כך טוב. אבל כאן בדיוק טמונה הבעיה, מי שעובד על VS2010 כמו שהוא עבד על VS6, עובד לא נכון ולא יעיל. כל גירסא באה עם החידושים שלה, וכל גירסא באה עם ה"ראש" שלה. זה שינוי פרדיגמה, שמחייב הסתגלות, ויש לו עקומת לימוד. דברים שהיית רגיל לעשות בצורה מסוימת, וקל ופשוט לך לעשות אותם ככה כבר 20 שנה, נעשים במערכת החדשה אחרת.

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

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

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

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

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

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

לכל הפוסטים שלי על VS2010 Beta 2.

אחד הכלים שנוספו לארסנל של מנתח התכנה הוא ה Architecture explorer.

הוא מופיע בתחתית כמו חלון ה Output, או חלון ה Call Hierarcy, אבל כמובן שניתן להזיז אותו לאן שרוצים, אפילו למסך השני, אם קיים. 

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

בתמונה אתם רואים במרכז גרף תלויות לפי Namespace אחד מהדוחות הדינמיים שדנתי בהם כבר בפוסט הקודם. בצד ימין המראה המוכר של ה Class explorer שאמור להיות מוכר לכולנו.

הפס מלמטה זה הכלי החדש

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

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

אני מניח שעד לרגע זה, יהיה מי שיגיד שאת כל זה קיבלנו כבר מה Solution explorere וה Class Explorere. והתשובה היא שזה נכון, אבל לא בדיוק. מערך השאילתה הדינמי, מאפשר לך למקד את החקירה שלך בשלבים, כאשר אתה מבצע תהליך של Drill Down. ויש לך גם (שים לב לסמל של המשפך) יכולות סינון לשאילתה, לפי המון פרמטרים. כך שאתה יכול להתמקד מהר ובקלות, רק במה שמעניין אותך. וכמובן בסוף, לכשמצאת את מה שרצית, אז כצפוי, לחיצה כפולה, ואתה מגיע ישירות לשורת הקוד הרלונטית.

מה שאולי ברור מאליו, אבל בכל אופן שווה למקד. זה שאתה יכול לעשות את התהליך הזה גם על קובץ ביצועי ולא רק על Solution. בחר קובץ

ותתחיל לחפור.

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

לכל הפוסטים שלי על VS2010 Bets2.

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

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

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

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

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

VS2010 Beta 2 כולל בתוכו אוסף כלים שיכולים לעזור רבות בתהליך האנליזה (וגם לקצר תיעוד). וחשבתי ששוה לכתוב קצת על כמה מהם.

בדרך כלל שאתה נכנס למערכת חדשה אתה רוצה לדעת בגדול ממה היא מורכבת. תפריט הארכיטקטורה ב VS2010 Beta 2 נותן לך אפשרות להוציא כמה דוחות מענינים לפי מה שמעניין אותך.

לדוגמא, דוח ה Assemblies נותן לך מבט מהיר מי נגד מי ברמת ה Assembly.

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

ולעומק,

בעצם עד איזה עומק שאתה רוצה.

היכולת שלך ליצר דוח מותאם אישית מאפשרת לך למשל להוציא די בקלות דוח של עץ הקריאות המלא

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

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

ניתן ליצא את כל הדברים האלה בפורמט DGML או XPS.

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

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

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

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

כל מה שתארתי כאן זה זה רק תת תפריט אחד, מבין עוד הרבה דברים חדשים שיש ב VS2010 Beta 2, תהנו.

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

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

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

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

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

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

אז מה בעצם סיכמתי לי מהדברים שאמרה מיכל (ואני מתנצל מראש אם לא זה מה שמיכל התכוונה לומר).

צפה להפתעות ושינויים, קבל אותם בהבנה ואהבה, זרום איתם, וראה בהם הזדמנות. או אם נשתמש בניסוח הלקוני יותר של MSF לנושא זה Embrace Changes. מה שאומר, שאתה כמנהל צריך לתכנן הכל, אבל להיות פתוח לכל הפתעה, ולשנות את התכנית בהתאם לצורך. הדואליות הזו של להכין תכנית מצד אחד ומצד שני לאלתר, קושרה כמובן מיד לעקרון הדואליות של גל וחלקיק.

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

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

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

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

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

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

מצד שני הגזמה בכיוון ההפוך לא נכונה. לאופטימיזר יש יותר "חוכמה" ברוב המקרים מאשר למתכנת. אם המתכנת מנסה לעשות אופטימיזציות חכמות מדי לקוד, הוא יכול למצוא את עצמו מפריע לאופטימיזר. ראיתי הרבה מקרים של Hint – ים שניתנו למנוע מסד הנתונים, שהיו שגויים, או לא היו אקטואליים יותר, כי אופי הנתונים השתנה לאורך הזמן. ראיתי גם הרבה קטעי קוד, שעושים קיצורים מגעילים, תוך שימוש ב Side effects, שבסופו של דבר רק הקשו על התחזוקה של הקוד והכי גרוע, מנעו מהאופטימיזר לעשות את העבודה שלו.

יש הרבה חוסר ידע, שגורם לכך שאנשים יעשו דברים בדרך איטית יותר. הדוגמא של דניאל היתה שימוש באיטרציה כדי להחליף בין שדות, כאשר משפט Update יודע לעשות את זה הרבה יותר מהר ובלי להתבלבל. בעולם התכנה זה שימוש למשל ב for I במקום For Each, על מרחבי נתונים לא לינאריים, שיש להם איטרטורים. כן אני יודע שכולכם יודעם את זה כבר אבל מתכנתים חדשים בצוות שלכם לא תמיד יודעים את מה שאתם יודעים.

לקחת בקוד החלטות אופטימיזציה שמתעלמות מכלל המערכת זה בדרך כלל טעות. קחו את השאלה הבאה, שאני תמיד שואל כאשר מדברים איתי על אופטימיזציה, והיא "לאיזה פרמטר אתה עושה אופטימיזציה בקוד שלך, למהירות או לגודל". התשובה הנפוצה היא למהירות, כדי ליעל כמובן כמה שיותר את פעולה היע"מ. תוצר לואי של ההחלטה הזו זה שהתכנית המיוצרת גדולה יותר, ותופסת יותר מקום בזכרון. במערכות עמוסות, ה Paging של התכנית הזו יהיה גדול יותר. ולמה זה חשוב ? להזכירכם, בזמן גישה אחת לדיסק, להביא דף אחד שנזרק החוצה בגלל העומס, מעבד ממוצע יכול לבצע 30,000,000 פעולות, ועוד ישאר לו עודף. כך שאולי במקרה כזה, צריך דווקא לעשות אופטימיזציה לגודל ולא למהירות ?

אחד הדברים שכואבים בתחום מסדי הנתונים, אבל רלונטיים לכל שימוש במנגנון מטמון במערכות תכנה רגילות, זה עד כמה אני יכול להרשות לעצמי, שהתמונה לא תהיה מעודכנת. דהינו, האם אני יכול לסבול שערך משתנה או נתון יהיו "לא נכונים" פרק זמן כלשהו או לחילופים האם המערכת יכולה לחיות עם "אי דיוקים".  אני יודע שאצל רבים זו בעיה לחשוב, שאתה עושה X=A+B ואחרי זה הערך של X עדיין לא יהיה הערך העדכני לפרק זמן מסויים. אבל אם אתה יודע בוודאות, שאף אחד לא ישתמש ב X לאותו פרק זמן מסויים, אין לך באמת בעיה. גם אם אתה יודע שהשינוי ב X, הוא כל כך קטן, שלא ישפיע באופן משמעותי על התוצאה הסופית, אין לך בעיה. הגמישות הקטנה הזו בזמן, מוליכה בסופו של דבר לחסכון עצום במשאבים. בעולם מסדי הנתונים זה חסכון בשאילתות על ידי שימוש במנגנון כמו Snap Shoot ובעולם הקוד זה שימוש בפחות סמפורים, בכל מקרה, זה שיפור ביצועים ללא צורך בתוספת תשתית.

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

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