-->

יום רביעי, 15 באוקטובר 2014

מהי התשתית (Framework) הטובה ביותר? [דעה]


נושא המעסיק אותנו תדיר, הוא נושא הפריון: כיצד לכתוב קוד קצר יותר ויעיל יותר.

מחקרים הראו השפעה של שפת התיכנות על הפירון, וכנראה שיש השפעה יותר גדולה ע"י שימוש בתשתיות (Frameworks) מתאימות.

אני הולך להמליץ לכם על ה Framework הטוב ביותר שנתקלתי בו, באמת!




האם זה Spring Framework?

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


בטח מדובר ב AngularJS - אין דבר חם יותר בשוק היום!

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


המסקנה הברורה היא בטח MeteorJs - מה יכול להיות יותר יעיל מ Angular?!

  - רעיון טוב, אבל לא.


מתחכם?

  - לא ממש. אין לי כוונה לסיים את הפוסט הזה עם קלישאה (נכונה) כמו: "כל כלי מתאים למשימה אחרת"...


אני רוצה להמליץ לכם באמת על משהו שהוא מבחינתי תובנה. לצורך הדוגמה (נאמר שמפתחים בצד-הלקוח) אציע לכם את התהליך הבא:
  1. לכתוב את המודול הראשון / הפרויקט הראשון ב Backbone.js
  2. במידה ויש הצלחה - לזרוק את Backbone. אם אין הצלחה - להמשיך איתו עוד סיבוב.
  3. לאחר שזרקתם את Backbone - ללמוד AngularJs, MeteorJs או React.js - והתחיל לכתוב בהם.

ברור לי שעל-פניה זוהי עצה מטופשת למדי!


אז מהי התשתית אותה אני מציע?
התשתית היא לא אף אחת מאלו שהוזכרו למעלה.







זוכרים את "הסיפור שאינו נגמר"?

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

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

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

(איזה סיפור נהדר!)




Opaque



Efficient Frameworks

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

בעצם, בתשתית הולכים לכתוב עוד הרבה מאוד מפתחים, והם הולכים להיות זריזים [א] (efficient) אך לא יעילים (effective) - כאשר הם לא מבינים מספיק טוב את הסביבה בה הם עובדים.

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

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

עבדתי בחברה, שהחליטה שהמפתחים שלה (שהוגדרו כעילויים, ברובם) לא מסוגלים לכתוב ב ExtJS - ספרייה לפיתוח צד-לקוח, שכבר בעצמה מחביאה כמעט כל מה שקורה בצד הלקוח במקבץ מרשים של רמות-הפשטה.
מה עשו? כתבו Framework נוסף, מבוסס XML, כדי להחביא עקרונות של ExtJS כמו MVC, ניהול אירועים, ועוד. "רק תגדיר איך המסך נראה ומה קורה כשלוחצים על כפתור" - הייתה שיטת העבודה.

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

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

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



Transparent


Effective Frameworks

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

תשתיות אלו הן תשתיות שהן באמת Transparent - רואים את כל מה שקורה. דוגמאות נפוצות יהיו Node.js (כמובן), Backbone.js (אותה ציינתי קודם), וגם מערכת ההפעלה Linux (בה כ"כ הרבה הוא גלוי למשתמש).

הזריזות של ה Frameworks ה Efficient, מפנה את עצמו ללמידה-מעמיקה מואצת של המשתמש. כשכותבים ב Backbone.js מחברים "בידיים" את ה View ל Controller וקושרים "בידיים" את האירועים. זו עבודה - אבל כל מי שכותב ב Backbone.js מבין דיי מהר כיצד פועל ה MVC בעולם של Backbone.

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

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

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

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

אם כן - מה עדיף?
להיות מהיר, או להיות יעיל?

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

גם חשוב מאוד לספק Delivery ולהתקדם מהר. כמה ארגונים יכולים "לספוג" מפתחים שמפתחים יותר לאט? נכון גם לשאול: כמה ארגונים יכולים "לספוג" מאסה של מפתחים שרק "מסתדרים" ולא ממש מבינים מה הם עושים?


אני מאמין, שהתשתית (Framework) הכי טובה שיש היא התשתית האנושית - מפתחים שמבינים מה הם עושים. אני לא חושב שמישהו יחלוק על כך: כולנו רואים כיצד המפתחים הבולטים יכולים לעשות כל-כך הרבה יותר. אני גם טוען שהתשתית האנושית לא יכולה להירכש רק על ידי גיוסים והדרכות - כפי שמקובל בתעשייה. אני מאמין שהדרך לשם היא לבחור במתכוון ובצורה אסטרטגית בסביבות עבודה בעלות-שקיפות (Transparency) בכל פעם שמתמודדים עם Domain חדש או טכנולוגיה חדשה.
סביבות בעלות פריון גבוה (נאמר: AngularJS או RoR) הן הסביבות המתאימות לאלו שכבר מבינים ועברו את שלבי הלמידה - ולא כתחליף ללמידה משמעותית של הטכנולוגיות, וסביבת-הריצה של המערכת.

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

אם אתם יכולים להתחיל בעבודה בתשתית Transparent בכדי להגביר למידה, ורק אז לעבור תשתית היעילה - עדיף. קודם תבנו את התשתית האנושית של ההבנה - ורק אח"כ תתמקדו בתשתית התוכנה שחוסכת שורות קוד.

הנה הנוסח, שהופיע בתחילת הפוסט:
  1. לכתוב את המודול הראשון / הפרויקט הראשון ב <ספרייה בעלת-שקיפות>.
  2. במידה ויש הצלחה בלמידה - לזרוק את ה <ספרייה בעלת-השקיפות>. אם אין הצלחה - להמשיך עוד סיבוב של למידה.
  3. לאחר שזרקתם את <ספרייה בעלת-השקיפות> - הרשו לעצמכם לעבוד ל<ספרייה אטומה שמתמחה ביעילות>.
יכול להיות שב domains מסוימים (למשל: עבודה ע"פ פרויקטים) - גישה זו כבר איננה משתלמת.

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


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


שיהיה בהצלחה!!



-

נ.ב. קשה לי שלא לראות את הקשר החזק בין רעיונות אלו, לרעיונות ה Lean Startup - מתודולגיה שהשפיעה עלי ועל תפיסותי עמוקות בשנים האחרונות.


----

[א] התרגום "זריז" ל Efficient מתאים לי יותר למטרות הפוסט. בלשנים - התמודדו!



20 comments:

  1. מסיבות דומות, מלמדים ברוב האוניברסיטאות c ואסמבלי לפני שפות עליות יותר (++c וג׳אווה).
    קשה, לדוגמא, להבין מה קורה בתוך ה-JVM או איך עובד ה gc ואיך להוציא ממנו את המקסימום ללא נסיון מסוים בניהול זכרון ובעבודה עם פוינטרים.
    רוב המכללות "חוסכות את המידע המיותר הזה" מהסטודנטים שלהם ומכינות אותם מהר יותר לשוק העבודה, כשהתוצאה היא בוגרים ברמה נמוכה יותר שאינם מצליחים להתרומם לרמה הנדסית גבוהה.
    (ברור שיש יוצאים מהכלל, בוגרי מכללות מבריקים, לרוב בזכות למידה עצמאית)

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

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

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

      מחק
  2. מה זה "מדלוורים" ?

    השבמחק
    תשובות
    1. הכוונה לגרסה עברית של המילה" Deliver", אולי "לספק תוכנה" (אני חושב שזה בניין פיעל - אבל אל תתפוס אותי במילה). כאשר יש תוכנה שצריך לסיים לכתוב אותה ולספק אותה למישהו בזמן מסוים, לרוב תחת לחץ.

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

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

    השבמחק
  5. מסכים עם מה שרן כתב.
    אני לדוגמא את הפרוייקט הראשון שלי ב-Web פיתחתי בASP.Net Webforms, שזו התשתית הכי פשוטה שידעתי להתמודד איתה.
    תוך כדי למדתי קצת JS ושכתבתי חלקים באתר עם-Knockout ו-Angular...
    מן הסתם היה עדיף שהייתי כותב את הפרוייקט בתשתיות המתאימות מלכתחילה, אילו היה לי את הנסיון וההיכרות איתם...
    בדיעבד אני שמח על הדרך שעשיתי, גם אם המעסיק קצת פחות... :)

    בקיצור, תודה על עוד פוסט נהדר!

    השבמחק
    תשובות
    1. היי,

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

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

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

      ליאור

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

    עמית

    השבמחק
  7. מאמר מעולה!
    מסכים עם כל מילה.

    השבמחק
  8. מאמר טוב, תודה!
    משהו שהיה חסר לי - מה הדרך הכי טובה לדעתך להעריך את מידת השקיפות ומידת היעילות\אטימות של ספריות תשתית מראש, כשאתה בוחן טכנולוגיות שאתה עוד לא מכיר?

    השבמחק
    תשובות
    1. היי נדב,

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

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

      ליאור

      מחק
  9. היי ליאור,

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

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

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

    השבמחק
  12. מתיש, לא ממש תורם כלום ומאכזב.

    השבמחק