בחירת טכנולוגיות לפרויקט עם מומחה פיתוח תוכנה

ארבעה שיקולים, ושלושה מדומים

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

צד לקוח, שתי שאלות

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

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

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

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

הבחירה שחשובה יותר מכל הכלים

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

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

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

מה חייב להיכרע עכשיו ומה יכול לחכות

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

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

מתי חדש כן מוצדק

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

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

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

איך אני עובד על זה

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

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