רובוטריקים: 50% מהיר יותר, אפס זמן השבתה. האם הקוד המסורתי שלך מעכב אותך?

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

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

הזדקנות קוד יכולה להאט כל חלק בעסק. מהדורות נמשכות זמן רב יותר, שינויים קטנים יוצרים באגים בלתי צפויים, ומפתחים חדשים צריכים שבועות כדי להבין איך המערכת עובדת. החלפת כל הפלטפורמה עשויה להישמע אטרקטיבית, אך שכתוב גדול יכול להפריע לפעילות היומיומית וליצור סיכונים חדשים. אני מעדיף גישה הדרגתית. הצוות שומר על הפעלת המוצר תוך שיפור בסיס הקוד בשלבים מבוקרים. ### התחל עם תצוגה ברורה של המערכת הנוכחית לפני שינוי הקוד, אני ממפה את החלקים החשובים ביותר: - פונקציות הליבה העסקיות - שירותים חיצוניים וממשקי API - חיבורי מסד נתונים - שלבי פריסה - אזורים עם פגמים תכופים - מודולים שקשה לבדוק - תכונות שלקוחות משתמשים בהן מדי יום סקירה זו עוזרת לצוות להפריד בין בעיות דחופות לקוד ישן שעדיין עובד היטב. שירות חיוב שמעבד תשלומים צריך לקבל יותר תשומת לב מאשר דוח פנימי בשימוש פעם בחודש. עידן הקוד לבדו לא אומר לי מה לשנות. השפעה עסקית, סיכון כשל ומאמץ תחזוקה נותנים מדריך טוב יותר. ### הגדר יעד מודרניזציה קטן בסיס קוד נעשה קל יותר לשיפור כאשר הצוות בוחר נקודת התחלה ברורה. יעד שימושי עשוי להיות: - צמצום שלבי הפריסה עבור שירות אחד - הוסף בדיקות אוטומטיות למודול בסיכון גבוה - החלפת ספרייה שאינה נתמכת - העברת פונקציה אחת לשירות נפרד - שיפור רישום שגיאות עבור זרימת עבודה מרכזית - שדרוג חלק אחד של האפליקציה לגרסת שפה נתמכת יעדים קטנים מקלים על מדידת ההתקדמות. הם גם נותנים לצוות דרך בטוחה ללמוד לפני נגיעה בחלקים גדולים יותר של המערכת. ### הגן על הקוד באמצעות בדיקות מודרניזציה ללא בדיקות יכולה להרגיש כמו שינוי מכונה בזמן שהיא פועלת. הצוות עשוי לשפר את המבנה ועדיין לשבור זרימת עבודה של הלקוח. אני בדרך כלל מתחיל עם מבחנים סביב ההתנהגות היקרה ביותר. בדיקות אלו אינן חייבות לכסות כל שורה. הם צריכים לאשר מה הבקשה חייבת להמשיך לעשות. עבור מערכת הזמנות מקוונת, בדיקות שימושיות עשויות לבדוק כי: - לקוח יכול להוסיף פריט לעגלה - רמות המלאי משתנות לאחר הזמנה מאושרת - תשלום שנכשל אינו יוצר הזמנה שהושלמה - החזר כספי מעדכן את סטטוס ההזמנה - אישור הזמנה מגיע לכתובת האימייל הנכונה בדיקות אפיון יכולות לעזור עם מערכות ישנות יותר. הם מתעדים את ההתנהגות הנוכחית לפני שהצוות משנה את הקוד הפנימי. גישה זו מועילה כאשר התיעוד מוגבל והאפליקציה הקיימת מכילה שנים של חוקים עסקיים. ### שפר את המבנה בקטעים קטנים קובץ גדול מכיל לרוב מספר תחומי אחריות. זה עשוי לאמת קלט, להחיל חוקים עסקיים, לשמור נתונים, לשלוח מיילים ולכתוב יומנים במקום אחד. אני מפריד בין תחומי האחריות הללו תחום אחד בכל פעם. התהליך יכול להיראות כך: 1. בחר פונקציה או מודול אחד. 2. הוסף בדיקות סביב ההתנהגות הנוכחית שלו. 3. הסר היגיון חוזר. 4. תן למשתנים ושיטות לא ברורים שמות טובים יותר. 5. הפרד את הכללים העסקיים מבסיס הנתונים או מקוד ממשק המשתמש. 6. הפעל את חבילת הבדיקה. 7. שחרר את השינוי בתהליך המשלוח הרגיל. שיטה זו מאפשרת לסקור כל שינוי בקלות. זה גם מקל על זיהוי המקור לבעיה אם מהדורה לא מתנהגת כמצופה. ### החלף רכיבים ישנים בנתיב הדרגתי שכתוב מלא נכשל לעתים קרובות מכיוון שהצוות משקיע חודשים בבניית תחליף בזמן שהמערכת הישנה ממשיכה להשתנות. הדרישות משתנות, כללים נסתרים מופיעים והגרסה החדשה גדלה בהיקפה. החלפה הדרגתית מצמצמת את הפער הזה. דפוס מעשי אחד הוא הצבת שירות חדש לצד המודול הישן. בקשות חדשות יכולות לעבור לשירות החדש בזמן שהנתיב הישן נשאר זמין למקרים שלא הועברו. הצוות יכול להשוות תוצאות, לסקור שגיאות ולהרחיב את הנתיב החדש לאחר שיוכיח את עצמו יציב. לדוגמה, חברה עשויה להעביר עדכוני פרופיל לקוחות לפני העברת היסטוריית החשבון. לכל חלק יש בדיקות ותוכנית שחרור משלו. משתמשים ממשיכים לגשת למוצר בזמן שההעברה מתקדמת. ### שמור על בטיחות שינויים במסד הנתונים עבודת מסד נתונים ראויה לתכנון קפדני מכיוון שקוד היישום והנתונים המאוחסנים תלויים זה בזה. אני נמנע משינויים המחייבים את גרסאות האפליקציה הישנות והחדשות להשתמש בפורמטים שונים של נתונים באותו רגע. העברה בטוחה יותר עוקבת לרוב אחר דפוס זה: - הוסף את השדה או הטבלה החדשים - תן לשתי גרסאות היישום להבין את המבנה הישן - העתק נתונים קיימים בקבוצות קטנות - התחל לכתוב למבנה החדש - קרא מהמבנה החדש לאחר אימות - הסר את המבנה הישן לאחר שהוא לא נחוץ עוד הצוות צריך לפקח על מהירות ההעברה, רשומות שנכשלו, עומס מסד הנתונים ואי התאמה בנתונים. יש לבדוק תוכנית גיבוי לפני תחילת ההגירה, לא במהלך תקרית. ### הפוך גרסאות קלות יותר לשליטה בסיס קוד מודרני עדיין יוצר סיכון אם כל מהדורה קשה לפריסה. אני מחפש דרכים להפוך את המסירה לניתנת לשחזור: - תצורת חנות מחוץ לקוד - השתמש בבדיקות בנייה אוטומטיות - הפעל בדיקות במהלך כל בקשת משיכה - צור את אותה חבילה עבור כל סביבה - שמור את שלבי הפריסה מתועדים - השתמש בדגלי תכונה לשינויים שצריכים שחרור הדרגתי - שמור על תהליך החזרה נבדק דגלי תכונות יכולים להפריד בין פריסה לשחרור ציבורי. הקוד יכול להיות קיים בייצור בעוד שהגישה מוגבלת למשתמשים פנימיים או לקבוצה קטנה של לקוחות. זה נותן לצוות זמן לצפות בשינוי לפני שהוא פותח אותו לכולם. ### הוסף ניטור שימושי יומנים ומדדים אמורים לעזור לענות על שאלות ספציפיות. נפח נתונים גבוה אינו זהה לנראות שימושית. עבור כל אזור מודרני, אני רוצה לדעת: - האם השירות זמין? - כמה זמן אורכות הבקשות? - באיזו תדירות נכשלות בקשות? - אילו שגיאות משפיעות על המשתמשים? - האם שיחות מסד הנתונים מאטות את זרימת העבודה? - האם הגרסה החדשה שינתה את התוצאות העסקיות? שירות תשלומים עשוי להזדקק להתראות על עסקאות שנכשלו ותגובות מושהות. תכונת חיפוש עשויה להזדקק לנתונים על תוצאות ריקות וזמן תגובה. הניטור הטוב ביותר משקף את האופן שבו אנשים משתמשים במוצר. ### שמור על מעורבות של אנשים מודרניזציית קוד אינה רק משימה טכנית. מנהלי מוצר, צוותי תמיכה, צוות תפעול ומפתחים עשויים כל אחד להכיר חלק אחר של המערכת. רשומות תמיכה יכולות לחשוף בעיות ומדדי קוד מחמיצים. מפתח עשוי לראות שיטה איטית, בעוד שסוכן תמיכה יודע שלקוחות נוטשים טופס כשלוקח יותר מדי זמן להגיב. אני מבקש מהצוותים לשתף: - אילו תהליכי עבודה גורמים לתלונות חוזרות ונשנות - אילו משימות ידניות גוזלות זמן מהצוות - אילו מהדורות יוצרות בקשות תמיכה - אילו אינטגרציות קשות לתחזוקה - אילו כללים עסקיים לא כתובים פרטים אלו עוזרים לצוות לבחור עבודה שמשפרת גם את הקוד וגם את המוצר. ### השתמש במדד הצלחה מעשי. יש למדוד את המודרניזציה באמצעות שינויים שהצוותים העסקיים וההנדסיים יכולים להבין. אמצעים שימושיים כוללים: - זמן הדרוש לשחרור שינוי קטן - מספר פגמים לאחר הפריסה - זמן מושקע באבחון תקריות - כיסוי בדיקות עבור זרימות עבודה קריטיות - תדירות החזרה לפריסה - זמן המפתח המושקע בתיקון בעיות חוזרות - זמן תגובה לפעולות מפתח של לקוחות המטרה היא לא לגרום לכל קובץ להיראות חדש. המטרה היא ליצור מערכת שהצוות יכול לשנות עם פחות סיכון ופחות מאמץ מבוזבז. ### נתיב יציב עובד טוב יותר משכתוב דרמטי. אני מתייחס למודרניזציה של קוד כתחזוקה שוטפת עם מטרות עסקיות ברורות. הצוות לומד את המערכת הנוכחית, מגן על התנהגות מפתח באמצעות בדיקות, משפר אזור אחד בכל פעם, ומשתמש בניטור כדי להנחות את ההחלטה הבאה. מוצר יציב לא צריך להפסיק בזמן שהקוד שלו משתפר. עם מהדורות קטנות, שינויים בטוחים במסד הנתונים ותוכנית החזרה לאחור, הצוות יכול לחדש את בסיס הקוד תוך המשך שירות ללקוחות. יש לנו ניסיון רב בתחום התעשייה. צור איתנו קשר לייעוץ מקצועי: איימי וו: amy.wu@ihuagroup.com/WhatsApp +8613612662976.

הפניות Martin Fowler, 2004, StranglerFigApplication Michael C Feathers, 2004, Working Effectively with Legacy Code Nicole Forsgren Jez Humble and Gene Kim, 2018, Accelerate Gene Kim Kevin Behr and George Spafford, 2013, The Phoenix Project Jez Humble and David Deliving Farley, Con2tinuous C. 2017, אדריכלות נקייה