למה הפסקתי לכתוב קוד והתחלתי לתכנן
פעם חשבתי שפיתוח תוכנה פירושו כתיבת פיצ'רים. חשבתי שהתפקיד שלי הוא ליצור ישויות (entities), לבנות בקרים (controllers) ולחבר מסדי נתונים.
פרויקט מהזמן האחרון שינה את נקודת המבט שלי. למדתי שקידוד הוא רק חלק אחד מהפתרון. העבודה האמיתית מתרחשת עוד לפני שכותבים שורת קוד אחת.
עליך להחליט על הארכיטקטורה. עליך לשאול מדוע היא מתאימה, מה העלות שלה, ואילו סיכונים היא פותרת.
הנה השיעורים העיקריים שלי:
• הארכיטקטורה חייבת להתאים לשלב המוצר. קל להתפתות להשתמש ב-microservices, Kubernetes ותורים מורכבים של אירועים (event queues) באופן מיידי. עבור הפרויקט שלנו, בחרנו בארכיטקטורה שכבתית (layered architecture) בתהליך יחיד (single process). זה אפשר לנו להפריד בין תחומי אחריות מבלי לסבול מהכאב ראש של מערכת מבוזרת. פשטות היא לרוב עדיפה כשמתחילים.
• חלק מההחלטות הן זולות עכשיו אך יקרות בהמשך. הוספנו TenantId למודל הנתונים שלנו מהיום הראשון. למרות שהיה לנו רק לקוח אחד, זה הפך מעבר עתידי למודל SaaS לקל. אם תחכו יותר מדי זמן כדי להוסיף multi-tenancy, המעבר יהפוך לסיוט.
• תכנון (Design) מונע מבוי סתם בעתיד. תכנות פותר בעיה מיידית. תכנון פותר בעיה מבלי לסגור דלתות לעתיד. השתמשנו ב-containers בשלב מוקדם כדי להקל על המעבר לתשתיות שונות. השתמשנו ב-interfaces כדי להפוך את החלפת הספקים לפשוטה.
• שינויים עסקיים מניעים שינויים טכניים. מערכת עוברת ל-microservices כי העסק צומח. אפליקציה של מרפאה אחת הופכת לפלטפורמת SaaS עבור מאות מרפאות. השינוי הזה משנה את הדרך שבה אתם מטפלים בחיובים (billing), מנויים (subscriptions) וסקיילביליות (scaling).
• אמינות דורשת תבניות (patterns) חכמות. עברנו מקריאות סינכרוניות (synchronous calls) לארכיטקטורה מונעת אירועים (event-driven architecture). במערכת רפואית, שירות התראות איטי לא אמור להפיל קביעת תור. השתמשנו ב-Outbox pattern כדי להבטיח שהנתונים יישארו בטוחים גם אם ה-message broker נכשל.
• תבניות חייבות להתאים לדומיין (domain). אל תשתמשו בתבניות באופן עיוור. אבחנה רפואית דורשת עקביות חזקה (strong consistency). אי אפשר להסתמך על עקביות סופית (eventual consistency) כשמדובר בבטיחות המטופל. אל תשתמשו ב-cache עבור נתונים קליניים רגישים אם זה פוגע ב-audit trail שלכם.
• DevOps הוא לא מחשבה בדיעבד. פריסה (deployment), בדיקות תקינות (health checks) וצינורות עבודה (pipelines) הם חלק מהתכנון הראשוני. עליכם להעריך עלויות ולבחור רכיבים שבאמת משרתים את הצרכים שלכם.
ההבדל בין מתכנת למעצב הוא ה"למה".
מתכנת שואל: "איך אני גורם לזה לעבוד?" מעצב שואל: "למה זה הפתרון הנכון לבעיה הספציפית הזו?"