להבין את כל הקוד-בייס זו לא המטרה (ועם סוכני AI, זה גם לא אפשרי)

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

המיתוס של המתכנת שיודע הכל

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

קוד הוא תוצר לוואי, לא המוצר

יש רעיון אמיתי מאחורי זה, ממאמר מ-1985 של פיטר נאור בשם "Programming as Theory Building". הטענה של נאור היא שהקוד עצמו הוא בעיקר תוצר לוואי. הדבר האמיתי שצוות בונה תוך כדי עבודה על תוכנית הוא תיאוריה משותפת עליה: תחושה אינטואיטיבית של למה היא עובדת כמו שהיא עובדת, שאף פעם לא ניתן ללכוד אותה במלואה בקוד או בתיעוד. זו הסיבה שלאבד את הקוד ניתן לתקן (אפשר לכתוב מחדש), אבל לאבד את האנשים שהבינו אותו זה אובדן הרבה יותר גדול. צוות בלי זיכרון ארגוני יכול להסתכל על קוד שעובד ועדיין להתקשות לשנות אותו בבטחה.

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

הבנה חלקית היא Trade-off, לא כישלון

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

TypeScript הוא דוגמה קטנה וקונקרטית לבחירה מכוונת ב-trade-off הזה. type checker לוקח על עצמו קטגוריה שלמה של דברים שאחרת הייתם צריכים להחזיק בראש - האם זה הטיפוס הנכון, האם העברתי את צורת הנתונים הנכונה - וברגע שהוא מטפל בזה במקומכם, ההבנה שלכם במכניקה הגולמית יורדת קצת. אבל היכולת שלכם לבצע שינויים נכונים מהר עולה. זה trade-off טוב. המטרה היא לא הבנה מקסימלית לשם עצמה. זו הבנה מספקת של הדברים הנכונים כדי לקבל החלטות טובות באופן עקבי.

מה משתנה עם סוכני AI

כאן זה נהיה מעניין לגבי איך אני בפועל עובד היום. סוכן AI לקידוד לא נושא זיכרון ארגוני בין sessions. כל שיחה חדשה מתחילה כמעט בלי הקשר על ההיסטוריה של הקוד-בייס, המוזרויות שלו, או ההיגיון מאחורי החלטות קודמות. זה שקול לקליטת מהנדס חדש לגמרי, מוכשר מאוד, מאפס - בכל פעם שפותחים thread חדש.

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

איפה זה משאיר אותי

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