צ'אד פאולר, 6Wunderkinder: "רק בקהילת המיחשוב 'מורשת' נחשבת משהו רע"

"חלק קטן בלבד מהפרויקטים הגדולים בתחום התוכנה מצליח באמת; הם לוקחים זמן ובסופו של דבר, התוכנות לא מחזיקות הרבה", אמר מנהל הטכנולוגיות הראשי של החברה בכנס Rails Israel 2013 של אנשים ומחשבים ● הוא טען שבעקבות כך, המפתחים של הדור הבא ישנאו את אלה של היום וכדי שזה לא יקרה, יש לכתוב את קוד התוכנה בקבצים קטנים

"רק בקהילת המיחשוב 'מורשת' (Legacy) נחשבת למשהו רע. זה לא צריך לקרות ואחת המחשבת שמלוות אותי כבר תקופה ארוכה היא איך לבנות משהו שיחזיק מעמד הרבה זמן. כשבודקים כיום פרויקטים גדולים של תוכנה רואים שרק חלקם הקטן מצליח באמת, כולל עמידה בזמנים – ומדובר בפרויקטים שלוקחים זמן רב. אני מעריך שמחזור החיים הממוצע של תוכנה עסקית הוא חמש שנים ואם לוקחים בחשבון את משך ההעמדה של הפרויקט, היא לא מחזיקה מעמד הרבה זמן. זה נורא. השאלה היא איך אנחנו יכולים ליצור משהו שיישאר כמורשת אחרינו, שישתמשו בו גם בפרויקט הבא", כך אמר צ'אד פאולר, מנהל הטכנולוגיות הראשי של 6Wunderkinder ואחד האנשים המוערכים ביותר בקהילת ה-Ruby on Rails. הוא נשא את הנאום המרכזי בכנס Rails Israel 2013, שהתקיים אתמול (ד') בסינמטק תל אביב.

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

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

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

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

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

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

קונסטנטין ציין שהכתיבה ב-Ruby צריכה להיות ברורה ולא כדאי להשתמש בקיצורים שיכולים לגרום לבעיות בהבנתה. הוא המליץ על Sinatra בגלל היכולת לכתוב באמצעותה קוד מהודק בצורה קלה יחסית.

עוד דיברו במליאה המרכזית של הכנס יהודה כץ, מאנשי Ember js – תבנית עבודה ליצירת יישומי רשת, שהציג כתיבת תוכנית מהירה תוך שילוב ושימוש בכלים שמציעה Ruby on Rails; חביאייר נוריה, יועץ Ruby, שהציג התמודדות עם מספרים עשרוניים קטנים ובעיות עסקיות שיכולות להיווצר עקב כך במערכת הימורים שמאפשרת גם הימורים בסכומים קטנים מאוד; ואנדרה ארקו, ממובילי קבוצת הליבה של Bundler, סביבת ניהול תלויות עבור יישומי Ruby, שהציג את ההבדלים בינו ובין השימוש ב-Rubygems.org.

תגובות

(0)

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

אין לשלוח תגובות הכוללות דברי הסתה, דיבה, וסגנון החורג מהטעם הטוב

אירועים קרובים