למי צלצלו הפעמונים
שלוש שאלות שאנחנו אוהבים להשאיר פתוחות וחבל: מי אחראי להקשיב לאזעקה כשדברים נשברים? מי מתעדף את התיקון? ואיזה דברים צריך בכלל לתקן?
מי אחראי להקשיב לאזעקה - של מי התפקיד לשים לב כשהגיבוי נכשל? כשסקריפט הבניה מזהיר שקבצי ה JS שהוא יצר גדולים מדי? שהקוד כולל יותר מדי חלקים דומים במקום תשתית משותפת? שהשרת מתחיל לעבוד יותר קשה ממה שאנחנו רגילים? "כל אחד יכול לראות את זה" בדרך כלל מוביל לזה שאף אחד לא שם לב.
מי מתעדף את התיקון - צריך להגיע לפרודקט בשביל להכניס פיצ'ר "הקטנת JavaScript"? זה עוצר ספרינט? נתפס ב Code Review? ואם שמתי לב אחרי המיזוג?
מה בכלל צריך לתקן - מתקנים כל מה שזורק Warning? רק אם ה Warning ממש מפחיד? רק אם יש זמן?
יש היום המון מנגנונים אוטומטיים שצועקים עלינו כשהקוד מזייף וככל שיש יותר מהם כך אנחנו מפתחים המון מנגנונים שמאפשרים להתעלם מאותם מנגנונים אוטומטיים. שמים Husky? תוך רגע אנחנו מגלים איך לבטל אותו. חייבים לעבור בדיקות בשביל לדחוף גרסה? נשים את הבדיקה ב skip רק לגרסה הזו. אנחנו מתעלמים מהאזהרות כי הרבה מהן הן False Positives. מתוך 3 הודעות שקיבלתי היום ב Code Review מ AI שלושתן היו טעויות של ה AI וכולן בזבזו לי זמן יקר לקרוא ולהבין למה ה AI התכוון ולמה הוא טועה. באותו זמן קובץ ה JavaScript במערכת כבר עבר את ה 5 מגה ואף אחד כבר לא זוכר מתי האזהרה על זה התחילה להופיע.
כמה רעיונות שיכולים לעזור:
אנחנו חייבים להחליט איזה בעיות מספיק חשובות בשביל לעצור את העבודה ואת כל השאר לכבות.
לכל תחום בפרויקט צריך להיות בן אדם שאחראי להסתכל על האזהרות. הוא או היא יקבעו מתי האזהרות יקפצו והם יהיו אחראים לצעוק כשיש בעיה שדורשת את זה, לפני שהמצב יחמיר.
הוק לפני קומיט זה לא רעיון טוב כי הוא לא מגיע לבן אדם הנכון בזמן הנכון. המפתח שעכשיו דוחף גרסה עם תלות ישנה צריך את זה לדמו של שבוע הבא וממילא יש משימה של שדרוג תלויות בספרינט הבא. עדיף שאחראי אבטחת מידע יקבל Push עם הפרטים ויחליט מה לעשות עם זה ואם באמת יש סכנה.
המטרה שלנו פשוטה - לפתח יותר מהר ועם פחות טעויות. מערכות תוכנה שצועקות על כולם על כל שטות לא עוזרות.