הערכה טכנולוגית מתחילה ב Trade Offs

21/05/2022

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

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

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

במילים אחרות - מה החסרונות של טייפסקריפט בפרויקט הספציפי שלכם?

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

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

נ.ב. הסקירה הזאת על ראסט: https://www.bunniestudios.com/blog/?p=6375 היא דוגמה מעולה לסקירה טכנולוגית שמציגה גם את העלויות ולא רק יתרונות מובהקים או חסרונות מובהקים.