הפוסט המקורי פורסם ב מרץ 2012 והוא לחלוטין עומד במבחן הזמן.
פוסט זה אני רוצה להקדיש לדבר היחסי ביותר בעולם — זמן
אל תגידו אין לי זמן!!! קראו את הפוסט עד הסוף
ביום יום שלי אני מלווה הרבה פרויקטי פיתוח, קטנים וגדולים ותיקים וחדשים.
אבל תמיד ולא משנה מה המצב אני שומע לא מעט את הסיבה ללא לעשות משהו כ "אין לי זמן" חייבים לעמוד בלו"ז!
למען האמת לא חסרים לי סיפורים איך אנשים שאני מכיר וגם עבדכם הנאמן יצרו זמן במקומות שלא היו פנויים בזמן. אני רוצה להתמקד ב 2 מיצגים, יש עוד בערך 50 נוספים
To VB or not To VB .NET
יצא לי לפני מספר שנים להיות מפתח בפרויקט שעבר לא מעט ידיים, בין 5 ל 8.
כמובן שפרויקט היה כתוב לפי כל השכבות כולל שכבת WEB עשירה.
למען האמת כתבו אותו לא מעט מפתחים מוכשרים עד מוכשרים מאוד.
אבל הנקודה הכואבת הפרויקט מומש ב VB.NET. אני הוא איש של C++ או C# ו VB זה ממש לא אני :-9. כאשר שאלתי למה לא כותבים ב C# אמרו לי שהתחלנו לכתוב את הפרויקט הגענו מ VB6 ולכן VB.NET זה היה הכי טבעי לנו. אז כמובן בהתחלה אמרתי OK ננסה.
לאחר כ 3 שעות מ(ה/ע)נות החלטתי שדי זה לא יכול להיות, כל קטע קוד שהייתי צריך לכתוב כתבתי בתוכנית בצד ב C# ולאחר מכן בעזרת reflector ראיתי איך צריך לכתוב ב VB.
צעד זה עזר לי בערך לעוד 4 שעות, כלומר משכתי יום שלם.
לאחר מספר ימים כאלו החלטת שדי אני חייב לעשות משהו בנדון, אני חייב לציין שכל הפרויקטים באותו זמן נכתבו ב C# וכולם ידעו C#.
שוב פעם באמצעות reflector המרתי את כל השכבות למעט שכבת ה UI ל C# זה לקח לי ………………………………. יומיים.
מאותו רגע היעילות שלי עלתה פלאים ואת המשימה שתוכננה ל שבועיים סיימתי ב שבוע (כולל ההמרה)
שיפור ביצועים או שיפור הפיתוח
אחד מהדברים שאני יודע לעשות ואוהב לעשות (ומקווה שעושה את זה טוב) זה לשפר ביצועים במקומות הקשים ביותר.
מקרה שקרה כך קרה, בפרויקט ענק שמבוסס WPF צוותי הפיתוח התלוננו על ביצועים גרועים במסכי תוצאות. כמו כל מערכת מידע מסכי תוצאות מגיעים אחרי מסכי שליפה. כל עצה שנתתי להם כיצד לנסות לשפר לקח למפתחים יום שלם להחזיר לי תשובה האם העצה עזרה או לא.
אתם בטח שואלים למה יום שלם? זה פשוט: קימופול אפליקציה –> הרצת האפליקציה –> העלאת צד שרת –> הבאת נתוני קונפיגורציה מהשרת –> הכנת נתוני שליפה –> ביצוע שליפה –> הצגת תוצאות במסך תוצאות, כמובן שבדרך השרת היה למטה, ה DB "נדפק" בגלל מישהו או כל סיבה מעכבת נוספת. לעצה שלי למה אתם לא בונים אפליקציה קטנה בצד קיבלתי את התשובה "אין לנו זמן זה כבר עובד בתוך האפליקציה שלנו".
לאחר זמן לא קצר וכמובן לאחר הרבה צעקות עד כדי רצון לוותר על WPF אמרתי לאחד המפתחים, תן לי יום אני רוצה לנסות לבדוק בעצמי.
בשעה הראשונה בניתי אפליקציה עם הXMAL של דף התוצאות. באותה שעה כבר לקחתי את הנתונים שהוכנו לתוך ה DataContext ובאמצעות DataContractSerializer הפכתי את ה DM ל XML.
מאותה נקודה לא הייתי צריך לא דף שליפה וכמובן שום צד שרת. כל בדיקה וניסיון שלי לקחו בדיוק 30 שניות ולא יום שלם. תוך פחות מיום שיפרתי את הביצועים ב 2.5 שניות ל 0.8 שניות וזאת רק ע"י ניסוי וטעייה.
כיצד מודדים זמן פיתוח, בואו ננסה לפשט
X- זמן הניתוח והעיצוב
Y – זמן הקידוד
I – זמן האינטגרציה
T – זמן הבדיקות
יש עוד לא מעט משתנים אבל למען הפשטות נשאיר זאת כך.
TOTAL=X+Y+I+T
כמובן שבעולם שלנו תמיד הזמנים לוחצים וצריך לספק תוצר ללקוח בזמן המהיר ביותר TTM.
ברור שהלקוח תמיד צודק, הוא רוצה בזמן מהיר תוצר איכותי ושנותן לו את כל היכולות שהוא ביקש. בואו נראה מה קורה בעולם האמיתי.
למשתנה X אף פעם אין זמן ושלא תבינו לא נכון צריך לתת ל X את הזמן הראוי לא אבל לא יותר מידי, לדוגמא ארכיטקטורה/עיצוב על למערכת הכי מורכבת לא צריך להיות יותר מחמישה ימים.
משתנה Y – כאשר תמחרו לנו את זמן Y ברור שתמחרו אותו ללא כל הדברים מסביב וכולם לחוצים שהמפתחים יסיימו כמה שיותר מהר. אז מה עושים…… כותבים קוד כדי שייתן מענה עסקי (אתם זוכרים יש לקוח בקצה) ואת כל השאר משאירים לסוף ומה זה כל השאר? טיפול בשגיאות, תיעוד , ביצועים, רישום ל LOG ועדכון העיצוב.
משתנה I – אחד מהנושאים הכואבים בכל פרויקט חומרה , תוכנה , ספורט וכדו' ככל שיש יותר שחקנים יותר קשה לבצע אינטגרציה.
משתנה T – שלא תתבלבלו בדיקות לא נועדו להוכיח שמה שפיתחנו תקין………… בדיקות נועדו לבדוק האם מה שפיתחנו "דפוק"
וכמובן שאתם כבר יכולים לראות מה קורה X<=>I<=>T<=>Y משפיעים רבות אחד על השני.
במערכת בריאה אנו נראה התכנסות, במערכת פחות בריאה נראה התבדרות
כמובן בגלל ההתבדרות שהיא בחוג פתוח (כדור שלג) נשמע יותר ויותר את המשפט "אין לי זמן"
האמונה שלי שתמיד אפשר לייצר זמן במיוחד במקומות שבהם קל להגיד "אין לי זמן".
אחד התפקידים שלי בתור ארכיטקט זה לייצר לכל השותפים בתהליך זמן.
אני רוצה לדבר על כמה חשובים
תהליך הנדסי
דעתי בנושא ידועה, אבל אני רוצה להמחיש אותה בסיפור קצר.
חברה ישראלית הייתה צריכה להקים פס ייצור לשם כך שכרה חברה אמריקאית שנתנה הצעת מחיר אטרקטיבית במועד סיום תואם לצורך חודש מתחילת הפרויקט.
הגיעו 3 מהנדסים אמריקאים שבמשך 3 שבועות ישבו וחשבו ורשמו רישומים, אבל שום פס ייצור לא התחיל לקום. כמובן שהישראלים היו לחוצים מה קורה עם פס הייצור? יש לנו לוחות זמנים. וכך שבוע לפני מועד הסיום פירקו המהנדסים את הציוד הרכיבו אותו חיברו לחשמל וביום ה "ש" אמרו שניתן להרים את החשמל. ברור שהכל עבד :-9
בקרה מסודרת וטווחים קצרים
כן אני יודע אתם חושבים ישר על Agile אבל זה לא רק זה. אפשר לעשות זאת בעוד מספר דרכים לא פחות טובות. הבסיס הוא פשוט אם תהליכי הבקרה יבוצעו בצורה מסודרת וידועה מראש (ללא תקורת זמן מיותרת) ונעשה זאת על פרק זמן קצר הטעות שתצטבר תמיד אבל תמיד תהיה קטנה. הרבה יותר קל לתקן טעויות קטנות בשוטף מאשר טעות אחת גדולה בסוף.
איכות קוד
קוד לא איכותי משפיע ישירות על Y,I,T גם בטווח הקצר וגם בטווח הארוך. בתוך ניסיון אני יכול להגיד בצורה ברורה השקעה מינימאלית באיכות קוד מייצרת באופן ברור חיסכון ב Y,I,T. ברור שניתן להגיע לזה במספר דרכים פשוטות כגון סקרי קוד, static code analysis , peer programming וכמובן "חיילות פרט"
כלים אוטומטיים
ללא ספק כלים אוטומטיים הם חסכני זמן לא קטנים.
אבל מה, הבעיה היא שאין לנו זמן להכניס לפרויקט תהליכים אוטומטיים בנושאים השונים כגון… build's , בדיקות יחידה/עומסים/UI/זיכרון, תהליכי הפצה , תהליכי בקרה וכו'
אז עושים זאת לאט ובזהירות
נא לא לדחות למחר מה שניתן לעשות עכשיו
בנקודה זו אני רוצה לתת דוגמא אשר תמחיש את העניין.
לוגים באפליקציה הם בעיני ההבדל בין חובבנות ולמקצוענות.
לצערי הרב ברוב המקרים המתכנתים רצים לכתוב קוד שנותן פונקציונאליות וכל השאר לא מעניין אותם את הלוגים בקוד הם ישאירו לסוף הפרויקט. ואני תמיד שואל למה לדחות???? הרי אני כבר נמצא בקוד אז למה לא להיות מפתח נחמד ולכתוב עוד כמה שורות קוד שיספקו לוגים/טיפול בשגיאות/הערות.
אני מבטיח לכם שלהוסיף את כל הדברים החשובים האלו בסוף הפרויקט זה דבר בלתי ישים בעליל, מה שקורה זה כשיש בעיות אז נזכרים בדברים האלו….. ואז זה לפעמים מאוחר מידי ומעט מידי.
אם נשקיע בשוטף יהיה לנו יותר זמן בהמשך, במקום לכבות שריפות נוכל לפתח דברים חדשים!
"אין לי זמן" לתכנן את הבדיקות הבודקים שלנו בעלי ניסיון.
הכוונה–> הבודקים שלנו הם בעצם הלקוחות
"אין לי זמן" לבצע עיצוב גרפי והנדסת אנוש.
הכוונה–> מה הלקוח עובד רק על סוג אחד של מסך ורזולוציה קבועה
"אין לי זמן" לבצע סקר קוד בכל מקרה הלוגיקה פשוטה.
הכוונה–> נו באמת סקר קוד זה אומר שהגרסה שלי תתעכב ותהיה יותר עבודה
"אין לי זמן" לבצע בדיקות זיכרון.
הכוונה–> מה זיכרון , הרי יש לאפליקציה 1G לפחות . הכי הרבה פעם בשעה שהלקוח יתחיל אותה מחדש
"אין לי זמן" לבדוק ביצועים.
הכוונה–> הלקוח לא שילם על ביצועים הוא שילם על יכולות, לביצועים תהייה עוד גרסה
"אין לי זמן" לבצע עיצוב על יש לי רק חודש לקידוד.
הכוונה–> זו באמת עשיתי זאת כבר עשרות פעמים למה צריך עיצוב הכול יושב לי בראש.
"אין לי זמן" לבדוק את המערכת בעומס.
הכוונה–> נו באמת בעולם של היום שיש ענן אז נגדיל את עוצמת המחשוב, בכל מקרה זה הלקוח משלם.
"אין לי זמן" זמן לתעד את הפיתוח.
הכוונה–> למה לתעד בכל מקרה אני לא אהיה פה במהדורה הבאה
"אין לי זמן" לחשוב על הנדסת תוכנה גם כך הפיתוח הוא זמני עד למוצר הבא.
הכוונה–> מה שזמני קבוע…… המוצר הבא יהיה בדור הבא.