איך בוחרים טכנולוגיה חדשה ומתי נוטשים את הקודמת

המאמר החביב הקודם שלי על כלי פיתוח לסביבת מק קיבל תגובות נחמדות ממש – חלק מהן שאלו אותי מדוע בכלי הפיתוח אני משתמש ב-nvm ולא ב-fnm. למי שלא יודע – שני הכלים משמשים לסביבת פיתוח מבוססת Node.js ומאפשרים לי לקבוע את גרסת Node.js. הכלי nvm הוא כלי ותיק ו-fnm הוא הכוכב החדש בשכונה.

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

הגדרת הבעיה: כלי, טכנולוגיה או סביבה חדשה לעומת stack חדש

בעולם הטכנולוגי, במיוחד בעולם הווב (פרונט אנד ובק אנד) יש שינויים תדירים בטכנולוגיה, בשפות תכנות אבל גם בסביבות. אני לא מדבר על סטאק טכנולוגי הכולל שפה כמו PHP למשל, או Node.js אלא על כלים טכנולוגיים בתוך סביבה מסוימת. כמו למשל כלי פיתוח, ניהול סביבה, ניהול חבילות וכן הלאה. למשל – בריאקט היה מקובל לעבוד עם create react app ועכשיו יותר עם vite. בג׳אווהסקריפט קלאסי (גם פרונט וגם בק) היה מקובל לעבוד עם ג׳אווהסקריפט ועכשיו עם טייפסקריפט. אלו בעצם כלים שונים וכלים כאלו יש כל הזמן. נשאלת השאלה – מתי זה זמן טוב לעבור אליהם?

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

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

עבודה היא ארגון, היא לא הסביבה האישית שלי

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

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

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

מתי להתקדם?

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

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

למידת טכנולוגיות חדשות – או לבחור לאן להתקדם?

יש כל כך הרבה טכנולוגיות חדשות שבאות והולכות – כמעט בכל תחום ובכל מקום. הדבר הראשון שאני נעזר בו הוא Technology Radar – סקירה טכנולוגית שבמסגרתה מציגים טכנולוגיות חדשות עם מידע עליהן וגם המלצה – לבחון, לאמץ או להעיף. יש לא מעט חברות שמציגות Tech Radar, למשל טיקל הישראלית היא אחת מהן שיש לה גם כנס שנתי סביב Tech radar ואפשר לבחון כמה ראדארים כאלו לפי בחירתכם.

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

הערכה בנוגע לכאב שהכלי החדש פותר – האם הוא פותר בעיה מהותית?

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

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

ואם הכלי החדש לא פותר בעיה מהותית? לא נעבור אליו?

אם הכלי החדש לא פותר בעיה טכנולוגית מהותית, אני אשתמש בו רק אם הכלי הנוכחי מתיישן והחדש הופך ליותר פופולרי דרמטית. למה? כי כלים מיושנים זה גם לא רעיון טוב – לקהילה יש חשיבות בפתרון בעיות – למשל אם הכלי שלי מיושן ולא פופולרי אז בעיות שאני אתקל בהן לא ייענו ב Stack overflow או בפורומים ואפילו Chat GPT לא יעזור כי לא יהיה לו המון על מה להתבסס.

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

1. מספר ההורדות השבועיות חודשיות – אם הכלי החדש עובר באופן קבוע בסדרי גודל את הכלי הישן – יש לזה חשיבות.
2. Google trends – אם יש יותר אנשים שמחפשים על הטכנולוגיה החדשה וגם פה באופן עקבי יותר – אז גם פה יש לזה חשיבות.
3. stackoverflow ומספר השאלות שיש שם – למרות שזוהרו הועם בגלל ג׳יפיטי וחבריו, עדיין מדובר בכלי חשוב להערכה של אימפקט של קהילת המפתחים.

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

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

לסיכום

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

אני ממליץ תמיד לכתוב או לנהוג לפי נוהל מסודר בנוגע לשדרוג והחלפת כלים, טכנולוגיות ואפילו שפות.

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