#8 ספגטיפיקציה

על החוק השני של התכנות, על מה שטוב בקוד מסובך, ועל קללת ה"גנריות"

מתוך ויקיפדיה:

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

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

התהליך הבלתי הפיך ובלתי נמנע בו קוד תוכנה נמתח ומסתבך ככל שהפרוייקט מתקדם.

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

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

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

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

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

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

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

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

והמהנדס החכם אומר: למה לעשות פשוט כשאפשר לעשות מסובך?