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

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

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

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

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

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

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