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

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

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

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

טיפ שעזר לי בבניית Micro Services טובים הוא להשאיר כמה שיותר נקודות התערבות, ולשמור כמה שפחות State. לדוגמא - אם יש לי סרביס שליחת מייל תזכורת שפונה לסרביס אחר כדי לקבל ממנו רשימת לקוחות, אני ארצה לבנות את סרביס המיילים עם שתי נקודות כניסה: ב Default הוא ייקח את רשימת הלקוחות מהסרביס שמחזיק את הלקוחות, אבל נקודת כניסה נוספת תאפשר הפעלה במעין Debug Mode, כאשר רשימת הלקוחות עוברת כפרמטר. בצורה כזאת אנחנו יכולים לבדוק כל אחד מהסרביסים בנפרד ולנסות שוב ושוב להריץ רק את הלקוחות שנכשלו.