יום ראשון, 22 בינואר 2012

תאימות לאחור

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