ספר הבישול של הקוד הפתוח: המדריך לאופה בפיתוח אפליקציות מודרני
ההשוואה בין תכנות Open Source ופיתוח אפליקציות מודרני לאפייה מאפשרת לבחון נושאים מורכבים דרך עדשות פשוטות יותר של מתכונים לעוגיות ● לפניכם טיפים ותובנות מהעולם הקולינרי, שיועילו גם באפייה וגם בפיתוח תוכנה עם רכיבי קוד פתוח
נהוג לומר שתוכנת קוד פתוח היא כמו מתכון. אם זה המצב, ניקח כדוגמה את העוגיות האהובות שסבתא שלכם מכינה. המתכון שלה לעוגיות שוקולד צ'יפס נחשב לטוב ביותר במשפחה, או שדווקא עוגיות הפקאן או עוגיות הסוכר שלה, שהולכות מצוין עם כוס תה. כך או כך, תרגישו בני מזל אם היא תסכים לשתף אתכם במתכון. אבל סבתא, מצידה, מבקשת שכאשר תכינו את העוגיות שלה בעצמכם, לא תשכחו להגיד לאורחים שזהו המתכון שלה.
למרות זאת מותר לכם תמיד לעשות שינויים במתכון לפי ראות עיניכם, וזוהי בדיוק המהות של תוכנת קוד פתוח – גם בה ישנם שלושת המרכיבים של המצאה מקורית, שיתוף פעולה, ומתן קרדיט ליוצר.
כשאופים או מבשלים, אנחנו משתמשים בצירוף כלשהו של הידע שלנו, מתכונים שקיבלנו מאנשים אחרים ועוד פיסות מידע או מרכיבים שרכשנו ממקורות אחרים. זוהי המהות של פיתוח יישומים מודרני: הקוד שאנחנו כותבים, הקוד שאנחנו שואלים ממישהו, והתוכנה שרוכשים ברישיון.
לא כל מתכוני הקוד הפתוח שווים
אז בואו נתחיל את ספר הבישול שלנו בבחירת המתכון. כולנו טעמנו מאפים מדהימים וכאלה שהיו פחות מדהימים. הופתענו לגלות שקרואסון שקנינו במאפיה השכונתית לא היה טעים כמו זה של בית הקפה הצרפתי שנפתח בפינה, או שלקרם פרש שקנינו בסופר לא היה אותו טעם כמו זה שהכנו בעצמנו בבית. בכל אחד מהמקרים ציפינו לתוצאה מסוימת, אבל קיבלנו חוויה שונה לגמרי. כאשר בוחרים מתכון, חשוב להבין איזה סוג של מאכל אתם מצפים להכין, כדי שלא תתאכזבו אם הטעם יהיה שונה לחלוטין ממה שציפיתם.
רכיבי קוד פתוח מציבים את אותו אתגר: בזמן ששני מרכיבים נושאים את אותו שם, הם עשויים להיות שונים מאוד זה מזה, בהתאם לספק שמכר לכם אותם. לדוגמה, הוואריאציה של ספק אחד למרכיב נתון של קוד פתוח (מה שבקהילת הטכנולוגיה קרוי distribution, או distro) דומה בעיקרון לזו של ספק אחר, אך יתכן שהוא הכניס בה שינויים קטנים כדי לענות על צרכים משלו (אם נשווה למשל את Red Hat Enterprise Linux ל-Ubuntu, בהקשר שלהן ללינוקס). השינויים הקטנים האלה ישפיעו על הפונקציונליות או התאימות, ויש להביא אותם בחשבון כאשר בוחרים רכיבי קוד פתוח לאפליקציה שאתם מפתחים.
במילים אחרות: היזהרו ממאפים שנושאים את אותו שם, אבל נאפים במאפיות שונות. ובעולם המפתחים: דעו מאין אתם רוכשים רכיבי קוד פתוח.
מתכוני קוד פתוח ממשיכים להתפתח עם הזמן
שום מתכון אינו מושלם בפעם הראשונה. לעתים קרובות נדרשים הרבה ניסיונות וטעימות, שכוללים גם הרבה כישלונות, עד שאנו מגיעים למתכון או לגרסה שאנו גאים בה. אני, למשל, אוהב להכין לחם בננות ויש לי ניסיון של קרוב לעשר שנים באפיית הלחם. אך במשך השנים ניסיתי לאפות את הלחם עם בננות בשלות, או בשלות מדי, עם שוקולד צ'יפס ובלעדיהם, עם אוכמניות ואגוזים ובלעדיהם. קיבלתי החלטות מודעות להוסיף חמאה, והחלטות לא מודעות, או טעויות, כמו למשל כאשר השתמשתי ביותר מדי מלח או סוכר. כל אחת מ"הגרסאות" שיצאו מהתנור שלי היתה עדיין "לחם בננות", אך כל אחת מהן הייתה שונה לחלוטין מבחינת טעם ומרקם. "מתכוני" קוד פתוח מתפתחים באופן דומה.
שינויים ברכיבי קוד פתוח יכולים להתבטא כגרסאות חדשות. פעמים רבות הם התוצאה של מאמצי פיתוח שנעשו במקביל לפרויקט העיקרי (שנקראים branches או forks). הענפים המסתעפים האלה (branches) יכולים לכלול פעילות פיתוח של מאפיינים חדשים, תיקוני באגים ובדיקות, ועם סיומם אפשר לשלב אותם בפרויקט העיקרי. הענפים יכולים גם להיות תוצאה של שיתוף פעולה בין כמה מפתחים, או של פעולה שאפתנית של אדם אחד. כך או כך, בכל גרסה חדשה של מרכיב מסוים אנו מתרחקים קצת יותר מהמקור של אותו רכיב (מ"הגזע" –trunk או master branch).
כאשר ספקים שונים מפתחים מרכיב מסוים ב-distros שונים, גדלה הסטיה מהגרסה המקורית שהועתקה. לזה קוראים "חוב טכני" (technical debt). לסטיה מהגרסה המקורית יש השלכות על תחזוקת הרכיב והתמיכה בו.
בקיצור: ככל שעובר הזמן, הפרשנויות של מאפיות שונות לאותו מתכון מובילות לתוצרים ייחודיים של כל אחת מהן. ובעולם הפיתוח: רכיבים מ-distros שונים נעשים יותר מובחנים זה מזה עם הזמן.
בחירת מתכון הקוד הפתוח
כמו בבישול ואפייה, כאשר משלבים רכיבי קוד פתוח ביישומים, חשוב להבין את מקורם ואת ההתפתחות של מה שמשלבים בתוכנה. בדקו בקפידה את גרסאות מרכיבי הקוד הפתוח ואת פעילותה של קהילת המפתחים כדי שתוכלו לחזות באופן המדויק ביותר את החוב הטכני שאתם יורשים. שני מרכיבים נפרדים נושאים את אותו שם, אך מקורם בשני distros שונים. לכל distro יש הסתעפויות ופיצולים משלו, המבטאים שינויים גדולים וקטנים. עם הזמן, הם מובילים לסטיה משמעותית בין שני סוגים של מה שנחשב בתחילה כאותו רכיב. אם לא תבינו לעומק את הדקויות של כל גרסה, הסטיה מהמקור תוביל גם לעלויות תחזוקה ופיתוח נוספות בעתיד, או תחשוף אתכם לבעיות אבטחה ותאימות.
הכותב הוא מנהל שיווק מוצר בחברת צ'קמרקס
תגובות
(0)