Backward compatibility כהתחייבות ארוכת טווח

אחרי ש-Deploy מסוכן, ואחרי ש-Gradual rollout התגלה כחרב פיפיות, נשארת ההבטחה השקטה מכולן:

שמה שעובד היום ימשיך לעבוד גם מחר.

האשליה: “לא שברנו כלום”

Backward compatibility נתפסת כהיגיינה בסיסית:

• לא שינינו חתימה
• לא הסרנו שדה
• לא שברנו לקוחות קיימים

נראה כאילו שמרנו על יציבות.

אבל זו אשליה חלקית.

Backward compatibility אינה מצב - היא התחייבות מצטברת.

כל API הוא הבטחה

ברגע ש-API יוצא לפרודקשן, הוא מפסיק להיות קוד.

הוא הופך לחוזה:

• עם לקוחות
• עם שירותים אחרים
• ועם העתיד של המערכת עצמה

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

המחיר הנסתר של תאימות לאחור

תאימות לאחור כמעט אף פעם לא עולה מיד. היא מתייקרת עם הזמן.

המחיר מופיע כ:

• לוגיקה כפולה
• קוד שלא ניתן למחוק
• בדיקות מורכבות
• וזרימות שאף אחד כבר לא מבין

כל “נשאיר את זה בשביל תאימות” הוא חוב עתידי.

למה “רק נוסיף שדה” מסוכן

“רק נוסיף שדה” נשמע תמים.

אבל בפועל:

• לקוחות מתחילים להסתמך עליו
• שירותים אחרים מעתיקים את ההתנהגות
• והוא הופך לחלק מהחוזה

גם אם לא תכננת - המערכת תכננה בשבילך.

Backward compatibility מתרחבת גם בלי כוונה.

מתי תאימות לאחור חונקת התקדמות

יש רגע שבו:

• אי אפשר לפשט
• אי אפשר לשנות
• ואי אפשר לשפר

לא בגלל מגבלה טכנית - אלא בגלל הבטחות עבר.

מערכות נתקעות לא כי הן מורכבות מדי - אלא כי הן מחויבות מדי.

מתי נכון לשבור במודע

שבירה אינה כישלון. לעיתים היא צעד אחראי.

שבירה מודעת:

• מתוכננת
• מתוקשרת
• ומוגבלת בזמן ובהשפעה

היא עדיפה על:

• סחיבת חוב לנצח
• מורכבות שמחלחלת לכל שכבה
• והאטה מתמשכת של המערכת

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

השורה התחתונה

Backward compatibility היא כוח - אבל גם משקל.

מערכות יציבות:

• יודעות מתי לשמור
• ומתי להצהיר על שינוי

לא מתוך קלות דעת - אלא מתוך אחריות לעתיד.

מבט קדימה

עד עכשיו דיברנו על מערכות ושינויים.

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

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