מהי התשתית (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 מתאים לי יותר למטרות הפוסט. בלשנים - התמודדו!