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

לא Spring Framework, לא AngularJS ואפילו לא MeteorJs – ליאור בר-און מציע מה היא לדעתו התשתית הטובה ביותר בשוק

מקור: Shutterstock

מקור: Shutterstock

נושא המעסיק אותנו תדיר, הוא נושא הפריון: כיצד לכתוב קוד קצר יותר ויעיל יותר. מחקרים הראו השפעה של שפת התיכנות על הפירון, וכנראה שיש השפעה יותר גדולה ע”י שימוש בתשתיות (Frameworks) מתאימות. אני הולך להמליץ לכם על ה Framework הטוב ביותר שנתקלתי בו, באמת!

האם זה Spring Framework?

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

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

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

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

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

מתחכם?

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

אני רוצה להמליץ לכם באמת על משהו שהוא מבחינתי תובנה. לצורך הדוגמה (נאמר שמפתחים בצד-הלקוח) אציע לכם את התהליך הבא:

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

ברור לי שעל-פניה זוהי עצה מטופשת למדי. אז מהי התשתית אותה אני מציע? התשתית היא לא אף אחת מאלו שהוזכרו למעלה.

מקור: ליאור בר-און

מקור: ליאור בר-און

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

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

Efficient Frameworks

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

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

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

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

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

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

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

מקור: Shutterstock

מקור: Shutterstock

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) הכי טובה שיש היא התשתית האנושית – מפתחים שמבינים מה הם עושים. אני לא חושב שמישהו יחלוק על כך: כולנו רואים כיצד המפתחים הבולטים יכולים לעשות כל-כך הרבה יותר. אני גם טוען שהתשתית האנושית לא יכולה להירכש רק על ידי גיוסים והדרכות – כפי שמקובל בתעשייה. אני מאמין שהדרך לשם היא לבחור במתכוון ובצורה אסטרטגית בסביבות עבודה בעלות-שקיפות (Transparent) בכל פעם שמתמודדים עם Domain חדש או טכנולוגיה חדשה.

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

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

מקור: Shutterstock

מקור: Shutterstock

הנה הנוסח, שהופיע בתחילת הפוסט:

  1. לכתוב את המודול הראשון / הפרויקט הראשון ב <ספרייה בעלת-שקיפות>.
  2. במידה ויש הצלחה בלמידה – לזרוק את ה <ספרייה בעלת-השקיפות>. אם אין הצלחה – להמשיך עוד סיבוב של למידה.
  3. לאחר שזרקתם את <ספרייה בעלת-השקיפות> – הרשו לעצמכם לעבוד ל<ספרייה אטומה שמתמחה ביעילות>.

יכול להיות שב-domains מסוימים (למשל: עבודה ע”פ פרויקטים) – גישה זו כבר איננה משתלמת.

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

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

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

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

—-

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

פורסם לראשונה בבלוג ארכיטקטורת תוכנה

מקור תמונות: Shutterstock / word cloud – software development , Perspective and underside angle abstract view to textured background of modern glass office building skyscrapers over blue cloudy sky at night , Program code and computer keyboard

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

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

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
שגיא
Guest

בזבזת לי 5 דקות מהחיים

valium
Guest
כתבה גרועה :-( אתה מחפש תשתית Framework לא רק כדי ללמוד או להסתיר מהצוות שלך בעיות. עדיף תשתית סטנדרטית שגם עובדים בה בצורה נכונה (מה שלרוב לא קורה). יותר מדי פעמים נתקלתי בחברות שבהן בשלב מסויים מישהו התחיל להוסיף אדפטציות משלו לתשתית (bootstrap למשל) רק שבמקום להוסיף שינויים חיצונית הוא/היא קידדו את השינויים לתוך הקבצים של התשתית – למה כי זה היה הכי קל. לצאת ממצב כזה הרבה יותר קשה מכיוון שיש לך קוד יעודי שלך מולחם לתוך ספריות התשתית. לכתוב משהו בספריה (נניח ב Backbone) ואז לזרוק את זה כדי ללמוד? לא עדיף אם התחלת ב Backbone להמשיך משם?… Read more »
אור
Guest

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

אורי
Guest

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

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

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

היום ה-time to market הוא הרבה יותר משמעותי מאשר איך זה יהיה כתוב או באיזה שפה, את המשתמש הסופי או את השוק זה ממש לא מעניין.

Radical Dreamer
Guest

ברגע שהוא השווה את Spring ל-AngularJS הבנתי שאין טעם להמשיך לקרוא…………
מזכיר לי הרצאה על האינטרנט של מישהי……

זוהר
Guest

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

Radical Dreamer
Guest

אתה גם לא מבין על מה אתה כותב……..
להשוות טכנולוגיית client-side לטכנולוגיית server-side זה פשוט …. סלח לי… פיגור.

NEXT.

בני
Guest

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

חיים
Guest

מכל הכתבה הזאת הבנתי שצריך לדעת AngularJS בשביל למצוא עבודה בשוק היום

boo
Guest
ליאור, קודם כל בדרך כלל אני מאוד נהנה מהמאמרים שאתה כותב. אבל במקרה הזה לדעתי אתה מפספס קצת. אני חושב שאתה צריך לעשות את ההבחנה בין שימוש בטכנולוגיית מדף של גוגל לבין “פריימוורק” פנים-ארגוני. ההשוואה לא רלוונטית מכמה היבטים: 1. הפריימוורק הפנימי בחיים לא יהיה מספיק מקיף ויסודי. 2. פיתוח ותחזוקה של פריימוורקים זה הדברים הכי לא lean ו-agile שיכול להיות. 3. אין דוקומנטציה. 4. עם כל הכבוד ל”מפתחים התותחים באירגון”, הם לא מגיעים לקרסוליים של המפתחים של גוגל, וכנראה רמת התשתיות תהיה בהתאם. לכן, למרות שאני גם לא תומך נלהב של הפריימוורקים הפנימיים, לא ברורה לי ההשלכה לשימוש בפריימוורקים… Read more »
יניב
Guest
כתבה טובה אם כי מנוסחת בעדינות לדעתי אחרי גיל 40 ומעל 20 שנות נסיון חייב לומר שנוצר פה דור של מפתחי ווב שלא מתקדם לשום מקום. תלוי לחלוטין בסיפריות חיצוניות שגורמות למפתחים להתעסקות פנימית במרחב הסיפרייה במקום לפרוץ קדימה ובנוסף חוסר ידע בדום, JS ו CSS שכשלעצמם פשוטים להפליא עם רף כניסה נמוך. חוסר ידע באיך בכלל עובד הדפדפן ברקע איך הוא מנצל את המשאבים של המחשב, איך עובד הדפדפן מול המערכת הגרפית ומול מערכת ההפעלה. הרי הקוד פתוח וגלוי אבל רוב מפתחי הווב הצעירים של היום לא בא מרקע NATIVE. בנוסף בעיות אבטחה חמורות , בעיות של רינדור UX… Read more »
סטארטאפיסט
Guest
הבעיה היא שהפרימוורקים הפכו לדת ולמטרה במקום לאמצעי. המטרה היא לספק תוכנה טובה. כל השאר – שטויות. אנגולר מאפשר לוותר על המון דברים שצריך לעשות ידנית ללא פרימוורק כזה ונותן למתכנתים להתעסק בעיקר – בביזנס לוג’יק, בשימושיות של המוצר ובפיצ’רים במקום לחפש או להוסיף אלמנטים בDOM ולהתעסק עם הדברים המעצבנים האלה. אבל… יש למהנדס (מהנדס, לא תוכניתן) אחריות אישית להבין איך עובד הפרימוורק, איך עובד המחשב, איך עובד מנוע הדפדפן, או השרת או מערכת ההפעלה או כל דבר אחר שהוא עוסק בו. באילו patterns הפרימוורק משתמש ואיך הוא מממש אותם וכו’ וכו’. ואז כשיש בעיות “מוזרות” אז רואים מי באמת… Read more »
טב
Guest

חבר הזכיר לי שכאשר הגיעה ג’אווה אמרו שמתכנתי ג’אווה הם לא מתכנתים אמיתיים כי הם לא מתעסקים בפויינטרים. כל דבר מעבר לשפת מכונה הוא סוג של הפשטה, אז חוזרים לאסמבלר כי רק ככה נתכנת באמת?
כשכתבתי את התוכנה הראשונה שלי על ZX-81, נדרשתי להתמודד עם אתגרים מורכבים כמו חוסר בזכרון (היה רק 1K). היום האתגרים קצת השתנו ואתם גם התשתיות שמאפשרות דברים מופלאים.
ידע הוא קודם כל דבר מצטבר ולדרוש מכל מפתח לעבור שלב של פיתוח תשתית MVC במקום להשתמש באחת כזו ואולי לקדם אותה הלאה, זה לא בדיוק חכם.
תשתית היא לא תחליף לשכל. והכי טוב להשתמש בשניהם.

Israel
Guest

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

תומר
Guest

“שאנו מגייסים עובדים”? עולה חדש כתב את הכתבה?

wpDiscuz

תגיות לכתבה: