תחזוקת תוכנה במחקר

מהדורת Python מהדורת JVM בלוג … ספרייה —> תחזוקת תוכנה במחקר מאת קונרד הינסן, פורסם ב-26 בפברואר 2014 תחזוקת תוכנה היא אחת הקשיים שבהם נתקלים באופן קבוע מפתחים של תוכנה מדעית. זוהי פעילות חשובה, אך היא עשויה לגזול זמן רב והיא כמעט אינה מתוגמלת על ידי נוהלי ההערכה הקיימים כיום. יתר על כן, אם אתם מנהלים פרויקט תוכנה גדול, השגת מימון לתחזוקה היא לרוב משימה קשה. לאור העובדה שתחזוקת תוכנה היא משימה קשה ואינה בעלת עניין מדעי מטבעה, עלינו לשאול את עצמנו מדוע היא נחוצה, והאם ניתן לעשות דבר מה כדי לצמצם את הצורך בה. ראשית כל, מהי תחזוקת תוכנה? מילון מרים-ובסטר מגדיר את הפועל “לתחזק” (maintain) כשמירה על משהו במצב טוב באמצעות תיקונים, תיקון בעיות וכדומה. הגיוני הדבר ביחס לציוד טכני המתבלה עם הזמן עקב שחיקה מכנית וכיוצא בזה. תוכנה אינה מתבלה, ולכן המונח “תחזוקה” חייב להתפרש אחרת כאשר הוא מיושם על תוכנה. איני מכיר הגדרה מוסכמת כלשהי, ולכן מה שאציג כאן היא הגדרתי שלי: תחזוקת תוכנה מורכבת משינוי התוכנה מאחת משתי סיבות: תיקון באגים. שמירה על שמישות התוכנה בסביבות מחשוב מתפתחות. יש שיצרפו לרשימה זו גם הרחבות פונקציונליות, אך הללו אינן בגדר תחזוקה במובן כלשהו, אלא שיפורים. הדבר נכון במיוחד במקרה של תוכנה מדעית, שבה פונקציונליות חדשה משמעה לעיתים קרובות מדע חדש. ראשית, באגים. כמו בכל תוכנה, אנו רוצים שבאגים בתוכנה מדעית יתוקנו כדי להשיג תוצאות טובות יותר בעתיד. עם זאת, אנו רוצים גם לשמור על הגרסה השגויה אם מחקר מדעי כלשהו שפורסם השתמש בה. זוהי פשוט סוגיה של יושרה ושל שמירה על הרשומה המדעית: אם קיים סיכוי שתוצאה של מחקר הושפעה על ידי באג בתוכנה, אנשים העוסקים במחקר זה צריכים להיות מסוגלים לגלות זאת. עליהם להיות בעלי גישה בדיוק לאותה תוכנה שבה נעשה שימוש במקור, ולא רק ליורש המשופר של ימינו. מסיבה זו, למעשה חשוב יותר לשמר את הקוד שנעשה בו שימוש במחקר מאשר לתקן באגים. ActivePapers תוכנן מתוך מחשבה על מטרה זו: כל פריט נתונים מחושב ב-ActivePaper מקושר לתוכנה שיצרה אותו. יתר על כן, קישור זה הוא בלתי ניתן לשינוי לחלוטין לאחר הפרסום, שכן ActivePapers מתפרסמים ממש כמו עותקים אלקטרוניים של מאמרים ומצוטטים באמצעות DOI. ניתן לרמות לפני הפרסום, על ידי שינוי ActivePaper בכוונה ספציפית לבצע הונאה. ActivePapers אינו תומך בפעולות כאלו, אך גם אינו נוקט כל מאמץ למנוע הונאה. ניתן היה להוסיף תכונות כאלו על ידי הגנת מידע המקור (provenance) באמצעות גיבושים (hashes), אך אני מקווה שזה לא יהיה נחוץ. הבעיה השנייה, סביבות מחשוב מתפתחות, היא עדינה יותר. זוהי עובדה מוגמרת שכל דבר בעולם המחשוב (מחשבים, מערכות הפעלה, מהדרים, הגדרות שפות, ספריות…) משתנה בקצב מהיר, והתוצאה היא שקוד מקור נתון ככל הנראה לא יעבוד כפי שהוא כמה שנים לאחר מכן. הדבר קורה משתי סיבות: (1) התקדמות טכנולוגית מאפשרת מחשבים ותוכנות טובים יותר ויותר, וזה מה שאנשים רוצים, ו-(2) אין לאף אחד אינטרס ממשי ביציבות של פלטפורמות מחשוב והכוח לגרום לכך להתממש. עבור יצרני חומרה וספקי תוכנה מסחרית, שינוי מהיר הוא הדרך הטובה ביותר להבטיח שלקוחות ירכשו מכונות חדשות ויחדשו את הרישיונות שלהם באופן קבוע. ישנה, כמובן, לפחות קהילה אחת שיש לה אינטרס ממשי ביציבות של פלטפורמות מחשוב: קהילת המדע החישובי. אילו יכולנו להריץ את התוכנה שלנו בעוד 20 שנה, ללא שינוי, ולקבל את אותן תוצאות, היינו שמחים. איננו רוצים לבצע תחזוקת תוכנה, ורובנו אינם יכולים בצורה סבירה לתחזק את התוכנה שהם מפתחים עבור המחקר שלהם מעבר לצרכיהם האישיים המיידיים. זה אף פחות סביר לצפות שמישהו יתחזק תוכנה של מישהו אחר, למשל התוכנה שהשאיר אחריו סטודנט לתארים מתקדמים שעובד כעת בתעשייה. בפועל, רק תוכנות קהילתיות בשימוש נרחב זוכות לתחזוקה לאורך תקופות מספקות. אך אפילו פרויקטים מחקריים המשתמשים בחבילות מתוחזקות ונפוצות דורשים לרוב גם תוכנה ספציפית לפרויקט, ולפחות כמה סקריפטים של מעטפת (shell scripts). וזוהי אחת הסיבות מדוע השחזוריות של מחקרים חישוביים היא כה ירודה. האם הקהילה המדעית יכולה לעשות דבר מה בנידון? אני מאמין שכן, אך איני אופטימי שהיא תנקוט פעולה בעתיד הקרוב. סביר להניח שמדענים ימשיכו להשתמש בחומרה סטנדרטית (commodity hardware) לחישובים מדעיים, כלומר הם יצטרכו לקבל את התפתחות החומרה ואת תוכנות המערכת הנלוות אליה, אשר נמצאות מחוץ לשליטתם. עם זאת, הם יכולים לבנות פלטפורמה יציבה על גבי פלטפורמות מתפתחות אלו, לפחות עבור החלק החישובי הטהור של עבודתם. ברמה הבסיסית, כל הסימונים לתוכנה שהם שלמים-טיורינג (Turing-complete) הם שווי ערך וניתנים להמרה זה לזה. בפועל, שיקולי ביצועים מטילים מגבלה על המרת קוד, אך עדיין ניתן להגדיר ייצוגי קוד הניתנים לתרגום ביעילות לכל סוגי החומרה ותוכנות המערכת הבסיסיות ובכך להישאר יציבים. שתי דוגמאות מהחיים האמיתיים הן קוד הבייט של ה-JVM והצורה הביניימית (intermediate form) של LLVM. קוד הבייט של ה-JVM קיים כבר 20 שנה והוכח כיציב ביותר. הצורה הביניימית של LLVM אינה מיועדת להיות יציבה, אך זאת משום שמפתחי LLVM אינם רוצים להגביל את האפשרויות העתידיות שלהם על ידי התחייבות לייצוג יציב. פרויקט PNaCl של גוגל מנסה להתעלם מאזהרה זו ולהשתמש בקוד LLVM באופן שיש לו היגיון רק אם הוא נשאר יציב. הזמן יגיד כיצד הדבר יתפתח. הקהילה המדעית יכלה להגדיר ייצוג קוד ביניימי משלה, תוך בנייה על הניסיון עם גישות קיימות ואופטימיזציה של הפלטפורמה שלה ליישומים מדעיים. אך, כפי שאמרתי לעיל, איני אופטימי שזה יקרה. שתי דרישות לכך היו מחויבות ארוכת טווח מצדם של מספר ארגוני מחקר ומימון גדולים לתחזק פלטפורמה זו לאורך עשורים רבים. אני משוכנע שזה יהיה משתלם כלכלית, כי אני בטוח שתחזוקת פלטפורמה אחת זולה יותר מתחזוקת חבילות תוכנה מדעיות רבות, ומכתיבה מחדש מתמדת של אלו שלא תוחזקו. אך הדבר ידרוש רמת הסכמה ומחויבות שהיא נדירה במדע; זה קרה רק עבור כמה מתקנים ענקיים כגון CERN. היתרון החשוב שמספקת פלטפורמה יציבה הוא הסיבה מדוע המהדורה הראשונה של ActivePapers תוכננה סביב ה-JVM. למרבה הצער, ה-JVM אינו פופולרי מאוד במחשוב מדעי. הדבר מוסבר לעיתים קרובות בחוסר ביצועים, אם כי טיעון זה אינו תקף עוד כבעבר. קיימות גם כמה בעיות עיצוב, במיוחד בנוגע לפעולות נקודה צפה (floating-point), אך אותו הדבר ניתן לומר על שפות פופולריות כמו C או C++, מה שלא מנע ממדענים להשתמש בהן. מהדורת ה-Python השימושית יותר מבחינה מעשית של ActivePapers בנויה על פלטפורמה המוגדרת על ידי מערכת האקולוגית של Scientific Python (בפרט Python, NumPy ו-h5py). פלטפורמה זו הוכחה כיציבה במידה בינונית בעבר, כאשר המעבר ל-Python 3 היה האירוע המרכזי של חוסר יציבות. קנה המידה הזמני שבו מדעי

קריאה נוספת

• SciPy — ויקיפדיה