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

1. האם יש כבר מערכת אמיתית שכתובה בטכנולוגיה זו?

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

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

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

2. מה מתאים לצוות שלי?

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

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

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

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

3. כמה קל להחליף?

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

כמה קל יהיה לכם להחליף חלקים במערכת או אף את כולה?

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

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

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