.jpg)
כשמדברים על סדר ו"ניקיון״ קוד - יש סקאלה של מצבים אפשריים:
• בקיצוניות אחת: ״בנה ותקן״ בו כותבים את הקוד המיידי ביותר האפשרי בכדי להפעיל את הפיצ׳ר הבא, מגלים באגים ואז הולכים לתקן אותן (ב- 20% מהפעמים או יותר יוצרים באג חדש).
• בקיצוניות שניה: פדנטיות קוד, בה כל קבוצת שורות של קוד עוברות refactoring וסידור על בסיס יומי. מקסימום סדר, מקסימום encapsulation, ולא גרם מיותר של אי-סדר בקוד.
לכאורה פדנטיות הקוד היא המצב ״הטוב״ ו'בנה ותקן' הוא המצב ״הרע״ ולכן רובנו שואפים לפדנטיות קוד אך לעולם לא מגיעים לשם, הדרך קשה מאוד ובמיוחד כאשר יש deadlines ו deliveries.כאשר אין deadline ו deliveries - אולי אפשר להתקדם כמה פסיעות נוספות לכיוון, אך עדיין קשה מאוד להגיע לסדר מופתי בקוד. יצא לי לבחון את הטענה הזו בעצמי: כשעבדתי ב SAP, בתקופה אחרת - ונתנו לנו מספר חודשים ״לסדר את קוד המערכת״ לפני שחרור ראשון של מוצר שעבדנו עליו. גם לאחר עבודה מאומצת עדיין לא הייתי מרוצה מהתוצאה. לא הגענו לקוד ״מושלם״ ונקי מבעיות.
הבעיה היא שכאשר נוסף פיצ׳ר נוסף למערכת - נוצר אי סדר מקומי קטן. תיקון אי הסדר הקטן מחלחל לאי-שלמות או סדר במובנים אחרים של המערכת - ודורש עוד השקעה בהתאמה, וחוזר חלילה.
כמו שגוף שמאיץ לכיוון מהירות האור הופך כבד יותר ודרושה אנרגיה גדולה יותר ויותר בכדי להמשיך להניע אותו ולהאיץ, גם ״סדר מופתי״ בקוד דורש מאמץ הולך וגובר עם הזמן. באותה מידה, כמו שמהירות האור היא יעד בלתי-מושג לגוף עם מאסה, כך גם ״סדר קוד מופתי״ הוא יעד בלתי אפשרי.
התועלת השולית משיפור איכות הקוד הולכת ופוחתת עם הזמן, אך מחירה הולך ומתייקר ככל שהקוד איכותי יותר.
מדוע בכלל לחתור ל״סדר מופתי״ בקוד?
לקוד של תוכנה יש בעיה גדולה של נראות (visibility): לערמה גדולה של קוד אין צבע, אין ריח, אין תחושה שניתן למשש או מרקם שניתן לראות.
כאשר דג במסעדה נרקב אזי הוא מעלה ריח, צבעו הופך דהוי, המרקם משתנה וגם תחושת המגע. יש לנו ,כבני אדם, מגוון חושים המאפשרים לנו לזהות בקלות מצב של ריקבון. כאשר בסיס קוד נרקב - אין לנו שום חוש או מנגנון טבעי לדעת זאת. הקוד הנרקב מרגיש, במבט-על, בדיוק כמו כל קוד אחר, אולי אפילו כמו הקוד הטוב ביותר שנכתב על כדור-הארץ.
מגוון כלים אוטומטים שהתעשייה והאקדמיה ניסו לבנות לאורך השנים בכדי לזהות ריקבון של קוד כשלו במבחן התוצאה:
• מתריעים על המון בעיות גם בבסיסי-קוד טובים, וגם בבסיסי-קוד לא טובים.
• תיקון הבעיות והגעה למצב ״טוב״ (ע״פ הכלי) היא בד"כ השקעה כלכלית לא יעילה: הרבה השקעה - ומעט ערך.
גם השימוש בבקשה של קבוצת מפתחים - לא הוכיח את עצמו לאורך השנים. מפתחים אוהבים את סגנון התכנות שלהם - אם הקוד דומה מאוד לקוד שלהם (למשל: הם כתבו אותו) – הקוד יעבור את המבחן. לעומת זאת, אם זה קוד זר ושונה – הוא יקבל ציון פחות טוב.
הדרך האמינה לזהות בסיס קוד רקוב בצורה דיי ודאית, היא מצב הריקבון המתקדם: צפיפות גבוהה של באגים + עלות גבוהה לתקן כל באג / לבצע שינויים. הבעיה היא שמצב כזה הוא כבר מאוחר מדי, ובד״כ יש צורך בשלב כזה לכתוב את בסיס-הקוד מחדש. הפתרון המקובל לבעיה הוא רחוק ממושלם, אך הוא הגרוע-פחות מהאלטרנטיבות המקובלות האחרות. מהותו: יצירת תרבות המקדשת איכות הקוד כערך עליון.
זה נשמע לכאורה כמו בזבוז אדיר, כי ברור ש״קוד מושלם״ איננו נקודת אופטימום כלכלית ליצירת התוכנה הטובה ביותר.
המזל הטוב מאיר בכך שרוב האנשים נשברים באמצע הדרך ל״קוד המושלם״ ובעצם לא משקיעים את כל המאמצים האדירים האפשריים. "החולשה האנושית" - מאפשרת לחתירה ל"קוד מושלם" להיות בעלת תוחלת כלכלית סבירה יחסית.
לשאיפה ל״קוד מושלם״ יש גם תופעות לוואי. פער הציפיות בין הרצוי למצוי גורם לתחושות תסכול מאי-ההגעה למטרה.
יש סברה למשל, שזו הסיבה שאין כמעט חברות תוכנה יפניות מצליחות. בתרבות היפנית - הפער והתסכול במקרה הזה הם בלתי-נסבלים. בתרבות ההודית, למשל - אין בעיה כזו.
היכן נמצאת ישראל? איפשהו באמצע. התסכול קיים, ושונה בין מפתח למפתח - כאשר עבור רוב המפתחים זהו תסכול נסבל, ורק למיעוט דקדקן - נגרם סבל ממשי ועמוק. התסכול / היעד הבלתי האפשרי הוא מחיר קיים שהתעשייה שלנו משלמת על מנת להתמודד עם חוסר היכולת לאמוד בצורה ברורה איכות של בסיסי-קוד.
מדוע אי אפשר פשוט לקום ולהחליט: ״בואו נעשה just enough הנדסת תוכנה / איכות קוד״ - על מנת להיות בנקודת אופטימום כלכלי? כל עוד אין לנו שום נקודת אחיזה אובייקטיבית ויעילה לגבי איכות הקוד, והאם היא מעל או מתחת לנקודת האופטימום (אפילו בקירוב) - לא ניתן באמת לנקוט בגישה ההגיונית הזו.
מה עושים?
האם אני מציע לוותר על ״איכות קוד״ כערך עליון ?זו בהחלט דילמה קשה: מצד אחד, ברור שחתירה ל"קוד מופתי" לא מובילה לנקודת אופטימום.מצד שני, כללים פשוטים וחד-משמעיים הם דרך יעילה להוביל קבוצת בני-אדם.
כללים חד-משמעיים הם כלי יסודי של הנהגה. ״איכות היא בראש!״ היא מניע עוצמתי וממקד, בעוד ״השקיעו באיכות במידה הנכונה!״ היא הנחיה מבלבלת שסביר שתזכה למידה הגונה של התעלמות.
סכנה נוספת היא "החלונות השבורים": כאשר אנחנו רואים עוד ועוד דוגמאות קוד ״עקומות״ במערכת - הנטייה האנושית היא לקבל את המצב הזה עד אשר קוד ״עקום״ כבר לא מפריע לנו.
כאשר אנו חותרים לקוד "האיכותי ביותר האפשרי" - סביר שנבזבז אחוז ניכר מהזמן שלנו ב״שיפורי איכות״ חסרי משמעות, או לפחות כמעט חסרי משמעות:
• הגנה בפני מקרי-קצה תאורטיים, שלעולם לא יתרחשו.
• לעתים מדובר בימים של עבודה רק כדי ש״הקוד יהיה מסודר״.
• הרחבת ה Framework / מבנה הקוד למקרים עתידיים - שלא עומדים להתרחש.
• ביצוע סידור גדול בקוד - רק על מנת לגלות חודש מאוחר יותר שהוא מגביל / לא נכון וצריך לסדר מחדש.
• פתרון באגים שלא מפריעים לאף אחד או לפחות לא יגרמו לשום impact עסקי שניתן למדוד.
• שיפורי UI חסרי-חשיבות:
• למשל התאמה של מסך אחד - שהיה עקבי יותר עם מסך אחר, אבל בעצם משתמשים שונים משתמשים בשני המסכים - אז כמעט אף אחד לא ישים לב.
• שיפור ביצועים - במקומות שלא זקוקים להם.
• ראיתי להרבה שיפורי ביצועים בחיים - שלעולם לא היו זקוקים להם, ורבים מהם בכלל לא היה ניתן למדוד מרוב שהם היו זניחים.
אז מה, בכל זאת, עושים?
גישה אחת היא להמשיך בדרך המקובלת יותר בתעשייה - הצבת איכות כערך עליון של הארגון.
גישה נוספת שאני רוצה להציע היא ניהול דינאמי של מצב איכות הקוד:
1. ננהל רשימה "חיה" של היבטים לא אופטימליים בקוד. את הרשימה כדאי לאסוף ממגוון חברים בארגון.
אם תנהלו את הרשימה הזו ברצינות - מהר מאוד תגיעו לעשרות פריטים ברשימה, ויותר. אם לא הגעתם סימן שלא חיפשתם מספיק טוב. זה כמו לשאול את עצמכם ״במה אני פחות טוב?״ - ולא למצוא שום דבר.
2. מתוך הרשימה - מצאו פריטים בעלי Impact: עדיף impact עסקי, אבל גם impact טכנולוגי - פחות בעיות, יתר קלות לקוד שנוסף למערכת, בקרה טובה יותר על המערכת וכו׳.
סביר שייקח לכם כמה סיבובים על מנת להבין היכן באמת נמצא ה Impact - רעיונות עלולים להישמע טוב, אך להיות חסרי impact לחלוטין בפועל.
3. תזמנו זמן עבודה מוגדר לצורך שיפורים יזומים ופתרון הפריטים החשובים ביותר ברשימה. ה benchmark הבריא שאני מכיר הוא כ 20% מזמן העבודה
פרשנויות שונות מה עושים בזמן הזה (כמו: ״באגים הם ברשימה״) - יכולים להפוך אותו ללא רלוונטי.
4. שווה לעבוד בצעדים קטנים. אם יש בעיה גדולה, הרשו לעצמכם למצמצם אותה ולראות מה ההשפעה העסקית שנובעת מכך. למשל: תהליך ה- deploy אורך 15 דקות? נסו לבצע שיפור (נניח: המקצר אותו ל-8 דק') ולראות מה ההשפעה בפועל. זה יותר טוב מלהשקיע פי כמה עבודה בכדי להביא אותו ל 2 דקות - ולגלות שה impact לא כ"כ משמעותי.
5. חשוב לערב את אנשי הצוות בהחלטות ובעשיה.
זה לא רק עניין של engagement ושותפות-גורל. זה גם עניין של ״חלונות שבורים״: לחדד ולהזכיר לכולם שקוד טוב הוא ערך חשוב - ושאנחנו כן משקיעים בו. ושהשקעה בו נושאת פרי.
הגישה הזו מעט קשה יותר לתפעול, במיוחד עם פעילות שוטפת שמושכת את רוב תשומת-הלב שלנו, אך מניסיוני, יש לה גם תוצאות טובות יותר.
גישה זו מאפשרת לנו להיות פחות ״מרובעים״ בנוגע לעבודה השוטפת ועדיין לשמור על קוד ״בריא״ מספיק על מנת שהמערכת תאריך חיים / ותספק גמישות לשינויים נדרשים. כל התחום הזה מאוד אפור וקשה להגדרה, היכן אפשר ״לוותר״ והיכן עדיין חשוב ולהקפיד? אין לי באמת הגדרות ברורות. בכל מקרה אנחנו לוקחים את ההחלטות דומות על סמך האינטואיציה.
הנה כמה פריטים מרשימות כאלו שניהלתי - שאכן עשו impact:
• פירוק של טבלה גדולה ב DB לכמה טבלאות - ע״פ דפוסי שימוש שונים.
• העברת נתונים מבסיס הנתונים ל Redis.
• שינוי הייצוג של הנתונים - למבנה קל יותר לעבודה.
• פירוק שרת Redis לשני שרתים ע״פ דפוס שימוש: כזה ל cache -וכזה לנתונים שחשוב שיישמרו. הפירוק אפשר לנו לנקות את ה caches ביעילות מבלי גרימת נזק.
• כתיבת מודול או microservice מחדש. צריכות להיות סיבות טובות למדי - לכתיבה מחדש (ופעמים רבות יש כאלו).
• שינוי מבני של flow מורכב במערכת.
• ניקוי קוד ישן / נתונים ישנים מבסיס הנתונים.
• הוספת כלי ניטור על מצבים חשובים במערכת - שחסרה נראות שלהם (דברים מאוד ספציפיים)
• Key Security Items
• Key Performance Items
• סידור נתונים ל BI
ברור שהיה עדיף למנוע מראש את היווצרות של המצבים הללו. בהינתן הדינמיקה הארגונית / הלחצים / וחוסר ידיעת העתיד - עד כמה זה באמת אפשרי?
ברור שזו רשימה ספציפית בהקשר ספציפי - שלא אוכל להעביר בפוסט.
הנה כמה פריטים שהיו ברשימות שכאלה, ולעולם לא הגיעו לידי מימוש:
• סידור flows מסוימים בקוד בכדי שיהיו פשוטים וברורים יותר (הרבה מקרים).
• HTTP being used internally (ולא https)
• מקרים מסוימים בהם כשל במיקרו-שירות אחד - גורר כשל במיקרו-שירות אחר
• Schemas שונים בבסיס הנתונים שנמצאים ב encodings שונים: אחד בשוודית והשני ב ISO.
• ניקוי ה git repository והסרת 25MB מיותרים.
• Various Security Items
• Various Performance Items
• סידור נתונים ל BI
• וכו'
להבהרה, אני לא ממליץ ליצור חוסר-סדר מכוון במערכת, הוא יגיע בכל מקרה - אין צורך לטרוח. מה שאני מציע הוא לא להילחץ מאי-סדר יותר מדי, וליצור תהליך מובנה להדוף את הצדדים הבעייתיים ביותר שבו.
מאמר זה הינו מאמר דעה
מאת: ליאור בר און, ארכיטקט ראשי (Chief Architect) בחברת Gett
http://www.softwarearchiblog.com
כשמדברים על סדר ו"ניקיון״ קוד - יש סקאלה של מצבים אפשריים:
• בקיצוניות אחת: ״בנה ותקן״ בו כותבים את הקוד המיידי ביותר האפשרי בכדי להפעיל את הפיצ׳ר הבא, מגלים באגים ואז הולכים לתקן אותן (ב- 20% מהפעמים או יותר יוצרים באג חדש).
• בקיצוניות שניה: פדנטיות קוד, בה כל קבוצת שורות של קוד עוברות refactoring וסידור על בסיס יומי. מקסימום סדר, מקסימום encapsulation, ולא גרם מיותר של אי-סדר בקוד.
לכאורה פדנטיות הקוד היא המצב ״הטוב״ ו'בנה ותקן' הוא המצב ״הרע״ ולכן רובנו שואפים לפדנטיות קוד אך לעולם לא מגיעים לשם, הדרך קשה מאוד ובמיוחד כאשר יש deadlines ו deliveries.כאשר אין deadline ו deliveries - אולי אפשר להתקדם כמה פסיעות נוספות לכיוון, אך עדיין קשה מאוד להגיע לסדר מופתי בקוד. יצא לי לבחון את הטענה הזו בעצמי: כשעבדתי ב SAP, בתקופה אחרת - ונתנו לנו מספר חודשים ״לסדר את קוד המערכת״ לפני שחרור ראשון של מוצר שעבדנו עליו. גם לאחר עבודה מאומצת עדיין לא הייתי מרוצה מהתוצאה. לא הגענו לקוד ״מושלם״ ונקי מבעיות.
הבעיה היא שכאשר נוסף פיצ׳ר נוסף למערכת - נוצר אי סדר מקומי קטן. תיקון אי הסדר הקטן מחלחל לאי-שלמות או סדר במובנים אחרים של המערכת - ודורש עוד השקעה בהתאמה, וחוזר חלילה.
כמו שגוף שמאיץ לכיוון מהירות האור הופך כבד יותר ודרושה אנרגיה גדולה יותר ויותר בכדי להמשיך להניע אותו ולהאיץ, גם ״סדר מופתי״ בקוד דורש מאמץ הולך וגובר עם הזמן. באותה מידה, כמו שמהירות האור היא יעד בלתי-מושג לגוף עם מאסה, כך גם ״סדר קוד מופתי״ הוא יעד בלתי אפשרי.
התועלת השולית משיפור איכות הקוד הולכת ופוחתת עם הזמן, אך מחירה הולך ומתייקר ככל שהקוד איכותי יותר.
מדוע בכלל לחתור ל״סדר מופתי״ בקוד?
לקוד של תוכנה יש בעיה גדולה של נראות (visibility): לערמה גדולה של קוד אין צבע, אין ריח, אין תחושה שניתן למשש או מרקם שניתן לראות.
כאשר דג במסעדה נרקב אזי הוא מעלה ריח, צבעו הופך דהוי, המרקם משתנה וגם תחושת המגע. יש לנו ,כבני אדם, מגוון חושים המאפשרים לנו לזהות בקלות מצב של ריקבון. כאשר בסיס קוד נרקב - אין לנו שום חוש או מנגנון טבעי לדעת זאת. הקוד הנרקב מרגיש, במבט-על, בדיוק כמו כל קוד אחר, אולי אפילו כמו הקוד הטוב ביותר שנכתב על כדור-הארץ.
מגוון כלים אוטומטים שהתעשייה והאקדמיה ניסו לבנות לאורך השנים בכדי לזהות ריקבון של קוד כשלו במבחן התוצאה:
• מתריעים על המון בעיות גם בבסיסי-קוד טובים, וגם בבסיסי-קוד לא טובים.
• תיקון הבעיות והגעה למצב ״טוב״ (ע״פ הכלי) היא בד"כ השקעה כלכלית לא יעילה: הרבה השקעה - ומעט ערך.
גם השימוש בבקשה של קבוצת מפתחים - לא הוכיח את עצמו לאורך השנים. מפתחים אוהבים את סגנון התכנות שלהם - אם הקוד דומה מאוד לקוד שלהם (למשל: הם כתבו אותו) – הקוד יעבור את המבחן. לעומת זאת, אם זה קוד זר ושונה – הוא יקבל ציון פחות טוב.
הדרך האמינה לזהות בסיס קוד רקוב בצורה דיי ודאית, היא מצב הריקבון המתקדם: צפיפות גבוהה של באגים + עלות גבוהה לתקן כל באג / לבצע שינויים. הבעיה היא שמצב כזה הוא כבר מאוחר מדי, ובד״כ יש צורך בשלב כזה לכתוב את בסיס-הקוד מחדש. הפתרון המקובל לבעיה הוא רחוק ממושלם, אך הוא הגרוע-פחות מהאלטרנטיבות המקובלות האחרות. מהותו: יצירת תרבות המקדשת איכות הקוד כערך עליון.
זה נשמע לכאורה כמו בזבוז אדיר, כי ברור ש״קוד מושלם״ איננו נקודת אופטימום כלכלית ליצירת התוכנה הטובה ביותר.
המזל הטוב מאיר בכך שרוב האנשים נשברים באמצע הדרך ל״קוד המושלם״ ובעצם לא משקיעים את כל המאמצים האדירים האפשריים. "החולשה האנושית" - מאפשרת לחתירה ל"קוד מושלם" להיות בעלת תוחלת כלכלית סבירה יחסית.
לשאיפה ל״קוד מושלם״ יש גם תופעות לוואי. פער הציפיות בין הרצוי למצוי גורם לתחושות תסכול מאי-ההגעה למטרה.
יש סברה למשל, שזו הסיבה שאין כמעט חברות תוכנה יפניות מצליחות. בתרבות היפנית - הפער והתסכול במקרה הזה הם בלתי-נסבלים. בתרבות ההודית, למשל - אין בעיה כזו.
היכן נמצאת ישראל? איפשהו באמצע. התסכול קיים, ושונה בין מפתח למפתח - כאשר עבור רוב המפתחים זהו תסכול נסבל, ורק למיעוט דקדקן - נגרם סבל ממשי ועמוק. התסכול / היעד הבלתי האפשרי הוא מחיר קיים שהתעשייה שלנו משלמת על מנת להתמודד עם חוסר היכולת לאמוד בצורה ברורה איכות של בסיסי-קוד.
מדוע אי אפשר פשוט לקום ולהחליט: ״בואו נעשה just enough הנדסת תוכנה / איכות קוד״ - על מנת להיות בנקודת אופטימום כלכלי? כל עוד אין לנו שום נקודת אחיזה אובייקטיבית ויעילה לגבי איכות הקוד, והאם היא מעל או מתחת לנקודת האופטימום (אפילו בקירוב) - לא ניתן באמת לנקוט בגישה ההגיונית הזו.
מה עושים?
האם אני מציע לוותר על ״איכות קוד״ כערך עליון ?זו בהחלט דילמה קשה: מצד אחד, ברור שחתירה ל"קוד מופתי" לא מובילה לנקודת אופטימום.מצד שני, כללים פשוטים וחד-משמעיים הם דרך יעילה להוביל קבוצת בני-אדם.
כללים חד-משמעיים הם כלי יסודי של הנהגה. ״איכות היא בראש!״ היא מניע עוצמתי וממקד, בעוד ״השקיעו באיכות במידה הנכונה!״ היא הנחיה מבלבלת שסביר שתזכה למידה הגונה של התעלמות.
סכנה נוספת היא "החלונות השבורים": כאשר אנחנו רואים עוד ועוד דוגמאות קוד ״עקומות״ במערכת - הנטייה האנושית היא לקבל את המצב הזה עד אשר קוד ״עקום״ כבר לא מפריע לנו.
כאשר אנו חותרים לקוד "האיכותי ביותר האפשרי" - סביר שנבזבז אחוז ניכר מהזמן שלנו ב״שיפורי איכות״ חסרי משמעות, או לפחות כמעט חסרי משמעות:
• הגנה בפני מקרי-קצה תאורטיים, שלעולם לא יתרחשו.
• לעתים מדובר בימים של עבודה רק כדי ש״הקוד יהיה מסודר״.
• הרחבת ה Framework / מבנה הקוד למקרים עתידיים - שלא עומדים להתרחש.
• ביצוע סידור גדול בקוד - רק על מנת לגלות חודש מאוחר יותר שהוא מגביל / לא נכון וצריך לסדר מחדש.
• פתרון באגים שלא מפריעים לאף אחד או לפחות לא יגרמו לשום impact עסקי שניתן למדוד.
• שיפורי UI חסרי-חשיבות:
• למשל התאמה של מסך אחד - שהיה עקבי יותר עם מסך אחר, אבל בעצם משתמשים שונים משתמשים בשני המסכים - אז כמעט אף אחד לא ישים לב.
• שיפור ביצועים - במקומות שלא זקוקים להם.
• ראיתי להרבה שיפורי ביצועים בחיים - שלעולם לא היו זקוקים להם, ורבים מהם בכלל לא היה ניתן למדוד מרוב שהם היו זניחים.
אז מה, בכל זאת, עושים?
גישה אחת היא להמשיך בדרך המקובלת יותר בתעשייה - הצבת איכות כערך עליון של הארגון.
גישה נוספת שאני רוצה להציע היא ניהול דינאמי של מצב איכות הקוד:
1. ננהל רשימה "חיה" של היבטים לא אופטימליים בקוד. את הרשימה כדאי לאסוף ממגוון חברים בארגון.
אם תנהלו את הרשימה הזו ברצינות - מהר מאוד תגיעו לעשרות פריטים ברשימה, ויותר. אם לא הגעתם סימן שלא חיפשתם מספיק טוב. זה כמו לשאול את עצמכם ״במה אני פחות טוב?״ - ולא למצוא שום דבר.
2. מתוך הרשימה - מצאו פריטים בעלי Impact: עדיף impact עסקי, אבל גם impact טכנולוגי - פחות בעיות, יתר קלות לקוד שנוסף למערכת, בקרה טובה יותר על המערכת וכו׳.
סביר שייקח לכם כמה סיבובים על מנת להבין היכן באמת נמצא ה Impact - רעיונות עלולים להישמע טוב, אך להיות חסרי impact לחלוטין בפועל.
3. תזמנו זמן עבודה מוגדר לצורך שיפורים יזומים ופתרון הפריטים החשובים ביותר ברשימה. ה benchmark הבריא שאני מכיר הוא כ 20% מזמן העבודה
פרשנויות שונות מה עושים בזמן הזה (כמו: ״באגים הם ברשימה״) - יכולים להפוך אותו ללא רלוונטי.
4. שווה לעבוד בצעדים קטנים. אם יש בעיה גדולה, הרשו לעצמכם למצמצם אותה ולראות מה ההשפעה העסקית שנובעת מכך. למשל: תהליך ה- deploy אורך 15 דקות? נסו לבצע שיפור (נניח: המקצר אותו ל-8 דק') ולראות מה ההשפעה בפועל. זה יותר טוב מלהשקיע פי כמה עבודה בכדי להביא אותו ל 2 דקות - ולגלות שה impact לא כ"כ משמעותי.
5. חשוב לערב את אנשי הצוות בהחלטות ובעשיה.
זה לא רק עניין של engagement ושותפות-גורל. זה גם עניין של ״חלונות שבורים״: לחדד ולהזכיר לכולם שקוד טוב הוא ערך חשוב - ושאנחנו כן משקיעים בו. ושהשקעה בו נושאת פרי.
הגישה הזו מעט קשה יותר לתפעול, במיוחד עם פעילות שוטפת שמושכת את רוב תשומת-הלב שלנו, אך מניסיוני, יש לה גם תוצאות טובות יותר.
גישה זו מאפשרת לנו להיות פחות ״מרובעים״ בנוגע לעבודה השוטפת ועדיין לשמור על קוד ״בריא״ מספיק על מנת שהמערכת תאריך חיים / ותספק גמישות לשינויים נדרשים. כל התחום הזה מאוד אפור וקשה להגדרה, היכן אפשר ״לוותר״ והיכן עדיין חשוב ולהקפיד? אין לי באמת הגדרות ברורות. בכל מקרה אנחנו לוקחים את ההחלטות דומות על סמך האינטואיציה.
הנה כמה פריטים מרשימות כאלו שניהלתי - שאכן עשו impact:
• פירוק של טבלה גדולה ב DB לכמה טבלאות - ע״פ דפוסי שימוש שונים.
• העברת נתונים מבסיס הנתונים ל Redis.
• שינוי הייצוג של הנתונים - למבנה קל יותר לעבודה.
• פירוק שרת Redis לשני שרתים ע״פ דפוס שימוש: כזה ל cache -וכזה לנתונים שחשוב שיישמרו. הפירוק אפשר לנו לנקות את ה caches ביעילות מבלי גרימת נזק.
• כתיבת מודול או microservice מחדש. צריכות להיות סיבות טובות למדי - לכתיבה מחדש (ופעמים רבות יש כאלו).
• שינוי מבני של flow מורכב במערכת.
• ניקוי קוד ישן / נתונים ישנים מבסיס הנתונים.
• הוספת כלי ניטור על מצבים חשובים במערכת - שחסרה נראות שלהם (דברים מאוד ספציפיים)
• Key Security Items
• Key Performance Items
• סידור נתונים ל BI
ברור שהיה עדיף למנוע מראש את היווצרות של המצבים הללו. בהינתן הדינמיקה הארגונית / הלחצים / וחוסר ידיעת העתיד - עד כמה זה באמת אפשרי?
ברור שזו רשימה ספציפית בהקשר ספציפי - שלא אוכל להעביר בפוסט.
הנה כמה פריטים שהיו ברשימות שכאלה, ולעולם לא הגיעו לידי מימוש:
• סידור flows מסוימים בקוד בכדי שיהיו פשוטים וברורים יותר (הרבה מקרים).
• HTTP being used internally (ולא https)
• מקרים מסוימים בהם כשל במיקרו-שירות אחד - גורר כשל במיקרו-שירות אחר
• Schemas שונים בבסיס הנתונים שנמצאים ב encodings שונים: אחד בשוודית והשני ב ISO.
• ניקוי ה git repository והסרת 25MB מיותרים.
• Various Security Items
• Various Performance Items
• סידור נתונים ל BI
• וכו'
להבהרה, אני לא ממליץ ליצור חוסר-סדר מכוון במערכת, הוא יגיע בכל מקרה - אין צורך לטרוח. מה שאני מציע הוא לא להילחץ מאי-סדר יותר מדי, וליצור תהליך מובנה להדוף את הצדדים הבעייתיים ביותר שבו.
מאמר זה הינו מאמר דעה
מאת: ליאור בר און, ארכיטקט ראשי (Chief Architect) בחברת Gett
http://www.softwarearchiblog.com
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר