Architect Master Class – Day one

מה זה Architect Master Class?

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

טיפה לפני שמתחילים

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

חלק ראשון - סקירת מהות הארכיטקט

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

Juval פתח ב "מקרה השרברב", האם כדי להחליף נקודת מים בבנין סלע צריך להחליף את כל הצנרת? אז למה בעולם התוכנה כן?
Juval ציין שבהרבה פרויקטים הרבה פעמים לא יודעים שהולכים לפספס את הלו"ז אלה רק מתי שהפרויקט ממש לפני הסיום
תמיד עולה השאלה למה מפתחים מופתעים שהדרישות משתנות?
ברוב הפרויקטים מפתחים דרישות שאין בהם שימוש
Juval העלה את סוגית איכות המפתח בתוך הקבוצה. האם המפתח הגרוע ביוצר בצוות הוא המפתח הגרוע ביותר בעולם? האם המפתח הטוב ביוצר בצוות הוא המפתח הטוב ביותר בעולם? כנראה שהתשובה על 2 השאלות היא לא...
Juval העלה עוד נקודה למחשבה, קוד שמפתח חזק כתב לא צמיד קל לתחזוקה לעומת זאת קוד שמפתח בינוני כתב יותר קל לתחזוקה.לכן אולי המפתח הבינוני צריך לפתח והחזק צריך לתחזק ?
למה צריך מערכת לניהול באגים? האם אנו מנהלים באגים לטוסטר?
מטוס גמבו יותר מורכב ומסובך מטוסטר אבל הרבה יותר בטוח :-9
זה לא נכון להגיד שיש ארגונים שאין להם תהליך פיתוח. לכל ארגון יש תהליך!!! בדרך כלל התהליך גורם לחוסר שיתופיות
Juval ציין את נושא הכשרות. הכשרת המפתח לעומת רופא או מהנדס מטוסים. אנחנו לא רואים את תהליך פיתוח התוכנה כתהליך הנדסי
המנהלים מתייחסים למפתחים כקופסאות שחורות. הכישורים נקבעים בצורה יבשה, אולי ניתן לראות את המפתחים כפועלי יצור?
Voodle – מושג ששמעתי כבר מאריאל גור אריה. מפתח מחפש לפי מילת מפתח, הלינק הראשון שמתקמפל נכנס לקוד שהולך ליצור, אף אחד לא יודע מה מקור הקוד/באג ותחשבו על זה....

לאורך כל ההרצאה של Juval הרגשתי תחושת דה ז'ה וו.

ארכיטקט זה לא מילה גסה

ארכיטקט סמכות ומה שביניהם

מתכנת, מפתח, מהנדס תוכנה -- השוני שבמילה

חלק שני - תהליך פיתוח מונחה שירותים

בחלק זה Juval התמקד בכיצד מפתחים בפרויקט מונחה שירותים

תהליך טוב הוא תהליך בלתי נראה, המחמאה זה לשמוע שלא מרגישים בתהליך
עבודה בקבוצות קטנות עד 7 אנשים, רק הם מתפקדות טוב. הכוונה ב 7 כולל כולם!
לא לשכוח היחידה שמתפקדת הכי טוב היא יחידה של אחד, לא תמיד היא הכי יעילה בסה"כ בכללי
סוג התהליך הוא לא הדבר החשוב. חשוב לדעת איך עושים אותו, מנהלים אותו ובאיזה כלים.
ISO לא אומר כלום בנושא זה, צריך לשאוף ל CMM רמה 3 עם חלקיות לרמה 4. בטוח לא פחות מ CMM רמה 2
כדי לעמוד בלוחות זמנים צריך ארכיטקטורה טובה ותהליך הנדסי טוב
Starbility – מושג חדש שלמדתי ואקח אותו איתי. Starbility מכיל את כל יעדי הנדסת התוכנה
זה לא משנה מה האפליקציה עושה אלה המורכבות של המרכיבים שלה. זה אחד מגורמים הכישלונות של פיתוח תוכנה
GANT ברוב המקרים גרוע לפיתוח תוכנה. הוא חייב להישאר ברמת על.
כמות הרכיבים למול עלות השילוב = עלות מינימלית- זהו תפקידו העיקרי של הארכיטקט
ארכיטקט כסוג של חונך. צריך לראות ארכיטקט בכיר חונך ארכיטקט צעיר. זה יחסים של WIN WIN
תפקיד הארכיטקט לחלק את המוצר שמפותח לשרותים עמידים בפני עצמם.
לאחר שלב התכנון יש לקיים פגישת feed me or kill me אם המנהלים רק לאחר מכן יש להתחיל לכתוב קוד
כאשר מתכננים בדיקות חייבים להקפיד לא להתייחס לקוד שנכתב כתינוק של המפתח, יש לבצע עליו את כלל הבדיקות הנדרשות ולא רק את אלו שיעברו כדי להגיד עברנו את הבדיקות. המטרה של הבדיקות לנסות למצוא מה לא בסדר ולא להוכיח שהמצב בסדר
מפתחים צרכים לבלות לפחות 20 אחוז מהזמן ב reviews שעושים להם או שהם עושים לאחרים
יש לפתח אפליקציית UI לבדיקת השרות, זה לא מחליף בדיקות יחדה.
מעבר ל SOA לא מקצר לוחות זמנים!!! והופך את הפרויקט ליותר מורכב.
כאשר נותנים הערכת זמנים נא לא לשכוח לקחת בחשבון : עקומת למידה,אפליקציית UI לבדיקה, התקנות, בדיקות, reviews ותיעוד
קיים משולש מנצח שבו הארכיטקט ומנהל הפיתוח צריכים לדאוג שיהיה מאוזן :
תכנון – אחריות מנהל הפיתוח והארכיטקט
התקדמות העבודה- רק הארכיטקט מאשר ששלב מסוים הסתיים
הזמן שהושקע – מנהל הפיתוח אחראי לקבוע כמה זמן הושקע ולנהל אותו
תיעוד הוא המפתח ל Starbility
ברמת התיעוד SRS שווה ל UC ולא לדרישות פונקציונאליות