דברים ש POC לא בודק

09/04/2018

בלינקדאין רצו לדעת איזה Framework לבחור לדור הבא של פיתוח ה Web שלהם. ההתלבטות היתה בין preact ל Glimmer. בשביל זה הם בנו את אותו הדף פעמיים: פעם אחת בכל ספריה, וראו מה עובד טוב יותר למתכנתים ולמשתמשים שלהם.

את הבדיקה המהנדסים של לינקדאין סיכמו בטבלא שהשוותה בין זמן העליה של המסך שפותח ב Glimmer לעומת זה שפותח ב preact. לא הפתיע אותי לגלות שהתוצאה היתה צמודה: הבדל של 40 עשיריות השניה בין הזמן לסיום עליית העמוד בשתי הספריות. הערכה שלי שגם אם היו מוסיפים להשוואה ספריות נוספות היו מצליחים להגיע לזמן עליה מאוד דומה.

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

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

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

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