backward compatibility ו forward compatibility

שלושה עקרונות חשובים בפיתוח תוכנה שכדאי להכיר במיוחד בעידן הבינה המלאכותית והקוד המהיר.

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

דיברתי עם הבן שלי, עומרי, שהוא מתכנת מנוסה בפני עצמו ועובד ב-Teads והוא כמובן:

  1. צחק עלי.
  2. אמר לי שאני זקן.

אבל אמר לי שזה יהיה רעיון נפלא לדבר על שלושה דברים – הראשון הוא Stability as a feature, והשניים האחרים הם backward compatibility ו forward compatibility. זה פוסט שהוא לא מאד טכני אבל הוא כן חשוב במיוחד בעידן ה-LLMים שמאפשרים לכל אחד לכתוב קוד אבל לא בטוח שקוד נכון.

אז נתחיל עם Stability as a feature. מכירים את ״ישן מפני חדש תוציאו״? אז בדיוק ההיפך. יציבות היא ערך ומה הכוונה ליציבות? זאת אומרת שאם יש לי קוד שעובד עם ממשק מסוים – למשל SDK או API, הוא ימשיך לעבוד עם הממשק. כך שמי שמשתמש בו לא יצטרך לשנות את צורת העבודה שלו. ייתכן ודברים כן ישתנו – ספריות תלויות ישתנו, יש תכונות חדשות שניתן להפעיל בנוסף, אולי יותר יציבות למוצר, אולי מאחורי הקלעים הוא יעבוד באופן שונה לחלוטין – אבל הוא יהיה יציב. זה לא קשור רק לקוד אלא גם לממשק. הממשק של אמזון למשל יציב למדי, הם לא משנים אותו המון וזה מאד מקל לכתוב להם הדרכות וספרים.

האם זה אומר שבעצם המוצר לא משתנה ומתעדכן? בוודאי שלא! אפשר לעדכן ולשנות אותו נונסטופ אבל עם הקפדה על שני דברים עיקריים. הראשון הוא… backward compatibility.

backward compatibility

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

<script language="JavaScript">
<!-- Hide script from old browsers

function greet() {
    var name = prompt("What is your name?", "Guest");
    if (name) {
        alert("Hello, " + name + "!");
    } else {
        alert("Hello, Guest!");
    }
}

greet();

// End hiding script -->
</script>

יש פה דברים שחלק מכם לא מכירים. קודם כל התגית language וההערה של החבאת הסקריפט, ה-var, פקודת ה-prompt וה-alert שבוא ונגיד שקשה לראות אותם in the wild עדיין עובדות. זה מראה שגם לדפדפן וגם לג׳אווהסקריפט עצמה יש backward compatibility – כלומר קוד בעבר יעבוד גם בהווה. את זה אנחנו מכירים. זה לא אומר שאין פיצ׳רים חדשים – הרי ג׳אווהסקריפט וגם הדפדפנים מוציאים פיצ׳רים חדשים בקצב של מתופף בפסטיבל מטאל – אבל זה אומר שהפיצ׳רים הישנים, טיפשיים ומגוחכים ככל שנחשוב עליהם, עדיין עובדים. זה מאד לא טריוויאלי אבל זה גורם למערכת להיות מאד יציבה.

forward compatibility

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

let x = 5;

הקוד הזה, שרץ יפה מאד על כל דפדפן מהעשור האחרון+, ייכשל בצורה מחרידה אם אני אריץ אותו על דפדפן ישן באמת. למה? כי let לא היתה עם משמעות מיוחדת בג׳אווהסקריפט.

דוגמה טובה ל-forward compatibility היא HTML. כן, כן, הסינטקס הישן והטוב מתוכנן לקבל כל תגית גם אם הוא לא מכיר אותה ומטפל בה כתגית inline לא מעוצבת. אם למשל ��יקח דפדפן של היום, ונכניס לו קוד HTML שיש בו אלמנט עתידני כמו תגית ai. בשעת כתיבת שורות אלו אין את זה בכלל אבל… אולי יהיה בשנת 2035? בשנת 2045? נכון. זה עוד עשרים שנה מזמן כתיבת שורות אלו, אבל הבלוג הזה בן 17 שנה (יאוזה!) ועדיין הפוסט הראשון שנכתב בו רלוונטי (!) ודברים יכולים להיות. ואולי הדפדפן שאני משתמש בו עכשיו יותקן גם בצוללת גרעינית ובחיים לא יתעדכן ובעוד עשרים שנה מישהו ייכנס לאתר וייתקל עם הדפדפן של היום בסינטקסט של עוד עשרים שנה? נניח קוד כזה:

<!DOCTYPE html>
<html>
<head>
    <title>Future Compatibility Demo with &lt;ai&gt; Tag</title>
    <style>
        ai {
            display: block;
            font-size: 1.2em;
            color: darkblue;
            border: 2px solid gray;
            padding: 10px;
            margin: 10px 0;
        }
    </style>
</head>
<body>
    <h1>Future Compatibility Demo</h1>

    <!-- Custom <ai> tag with hypothetical props -->
    <ai name="chatbot" version="1.0" mood="friendly">
        Hello! I'm a custom <ai> element!
    </ai>

    <script>
    // Access the custom <ai> tag
    var aiElement = document.querySelector("ai");
    console.log("AI Element Props:");
    console.log("Name:", aiElement.getAttribute("name"));
    console.log("Version:", aiElement.getAttribute("version"));
    console.log("Mood:", aiElement.getAttribute("mood"));

    // Future Compatibility Issue:
    // If a future browser introduces a native <ai> tag with its own behavior and attributes,
    // this custom implementation might break or behave differently.
    </script>
</body>
</html>

אתם יכולים להריץ אותו. הוא יעבוד – למרות שתגית ai לא קיימת והמצאתי אותה, הקוד הזה יעבוד בדפדפן של היום. נכון, הפונקציונליות לא תעבוד בדפדפן של היום, אבל הוא לא יקרוס ויתפוצץ כמו דפדפן של לפני עשרים שנה כשהוא מקבל ג׳אווהסקריפט מודרני. וזה בדיוק forward compatibility.

סיכום

למדנו שלושה מונחים בתחום הנדסת תוכנה. בעידן של LLM בו קל לייצר קוד, לצערי עדיין צריכים את הטאץ׳ האנושי בהדרכה והכוונה של כתיבת הקוד וחלק מהטאץ׳ הזה הוא מחשבה קדימה. איך אנחנו ב��נים קוד שלא נשבר בכל שינוי – בין אם מדובר בתוכנה או מדובר ב-API ואיך אנחנו צופים פני עתיד ובונים קוד שיהיה גמיש גם לשינויים עתידיים. מקווה שהצלחתי לעניין ולסקרן. אולי גם את הקוראים של עוד 17 שנה.

פוסטים נוספים שכדאי לקרוא

גלילה לראש העמוד