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

ואולי Virtual DOM הוא לא כזה רעיון טוב? או לא כזה מתאים לפרויקט שלך?

ואולי ORM לא היה כזה רעיון טוב? או לפחות לא הכי מתאים לפרויקט שלך?

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

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

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

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

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