מה הקשר בין עץ אשוח לקוד פתוח?

 

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

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

מה המוטיבציה?

לא להמציא את הגלגל..

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

למה הרבה יותר טוב?
כי לקוד פתוח יש super power

כוחות על שמגיעים מהקהילה

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

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

וכך באופן טבעי צפות בעיות, מועלים פתרונות ופרויקטים כאלה רק הולכים ומשתפרים.
 

אז מה הרווחנו?

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

מהירות פיתוח - שימוש בקוד פתוח הופך את הפיתוח שלנו להרבה יותר מהיר, ומאפשר לנו להתעסק יותר בתכלס, בbusiness logic של הפרויקט שלנו.

וכל זה בחינם?!

בקיצור, זורקים כאן סוכריות..

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

זה ביחד עם copy paste מstack over flow כמובן.

אבל.. איך אני יודע שהסבתא החביבה שמחלקת לי סוכריות, היא לא הזאב הרע בתחפושת?

 

 

אז איך נזהרים מהזאב הרע?

כמו כל החלטה בתכנון הקוד, צריך לדעת שכאשר באים לשלב קוד פתוח בקוד יכול להיות לזה trade-off.

כאן עולות שאלות של ביצועים, אבטחה ותלות.

1. ביצועים - נשאל את עצמנו את השאלה הידועה, האם כדאי להוציא את הפרארי מהמחסן בשביל נסיעה של דקה למכולת?
לפעמים שימוש בקוד פתוח יכביד לנו על הקוד.
מוצר web שעוסק בפרסומות לדוגמא, או בכל תחום שלא יכול להתפשר על מהירות, יכול להיות מאוד שיעדיף לכתוב קוד בvanila js על פני פריימוורק אחר, רק בשביל שזמן הטעינה של האתר יהיה מהיר יותר בכמה שברירי שנייה.
או לחלופין, יש מי שיעדיף לממש מערכת טסטים בעצמו ולא להשתמש בjest הפופלרית בגלל שזו, טוענת בעלייה שלה הרבה ספריות נוספות שלא תמיד נחוצות למשימה.

אגב אלה דוגמאות מהעולם האמיתי, את הראשונה שמעתי מראש צוות בראיון עבודה, ואת השנייה מגיל תייר בפודקאסט frontendland.

2. אבטחה - נושא שאולי עוד יותר חשוב להכיר כאשר מתחילים להשתמש בקוד פתוח בתוך הקוד, הוא security.
כמה קל לכתוב חבילה שפותרת איזשהי בעיה, ופשוט על הדרך להחדיר קוד זדוני לחבילה..

ואפילו יותר קל מזה, לא צריך להמציא את הגלגל, רק להעתיק חבילה ידועה, נניח עם מיליון הורדות בשבוע, לשנות את השם שלה שינוי קל, לדוגמא להעתיק את react-dom ולקרוא לה react-dum.
החבילה החדשה, הזדונית, יכולה לממש את אותו api של החבילה המקורית ועל הדרך, ובלי ששמנו לב, יש לנו תוכנה זדונית בקוד, רק בגלל שכתבנו את שם החבילה לא נכון.

 

3. תלות - עוד שאלה שיותר נוגעת בתכנון של הקוד, היא כמה הקוד שלנו תלוי בקוד הפתוח שאנו משלבים בתוכו. אם מחר לדוגמא החבילה שהכנסנו בקוד הופכת להיות deprecated, האם נוכל להחליף אותה בקלות באלטרנטיבה?
בכללי, יש לתת את הדעת לשאלת התלות, אם בחרנו לבסס את הקוד שלנו בצורה ישירה על open source, האם יש סביבו קהילה? האם יש תמיכה והמשך פיתוח של החבילה/ הספרייה/ הפריימוורק המדובר? האם יכול להיות שאנחנו מבססים את כל הפרוייקט על חבילה מסויימת שמחר לא תתמך יותר?

 

אנסה לתת לבעיות אלה כמה פתרונות.

 

עצי אשוח וגם כמה פתרונות אפשריים

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

Npm ראשי תיבות node package manager - למי שלא מכיר, זו הפלטפורמה כנראה הפופולרית ביותר לשיתוף חבילות בjs, היא מספקת לנו המפתחים דרך קלה להתקין חבילות קוד פתוח בפרוייקט.
סקירה על החבילות ניתן לקבל באתר npmjs.com, בו ניתן למצוא חבילות מתאימות לנו, ולקבל עליהם מידע נוסף.

כשלמדתי לראשונה להשתמש באתר של npm, מייד שמתי לב לעובדה מעניינת
כמעט בכל גרף הורדות של כל חבילה פופולרית, יש בור!

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

מה שמעניין שהצורה הזאת של השבירה בהורדות, חוזרת על עצמה לדעתי ב98% מהחבילות הפופולריות.

בוא ניתן דוגמא מכמה ספריות מוכרות, נניח - react, express וloadash.



שימו לב לצורה הדומה של הגרף

 

כשראיתי את עקביות התופעה, סקרן אותי להבין מה קרה,
והאמת שזה די ברור,
השבוע של חג המולד עד השנה האזרחית החדשה, הוא השבוע בו יש ירידה משמעותית בכמות ההורדות.

זה כנראה נובע מהעובדה שחלק גדול ממפתחי העולם נמצא בחופש בתקופה הזו.
אגב מדובר בממוצע של 30% ירידה בהורדות בשיא הירידה (הנתונים נבדקו באומדן).
 

ומה קורה בפרוייקטים פחות פופולריים?

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

דוגמא-
 

ואיך כל זה קשור לפתרון?

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

אז מה הם הדברים שכדאי לבדוק כשניגשים לבחון ספריית קוד פתוח?

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

פופולריות- פופולריות נמוכה, יכולה לפעמים להדליק לנו נורת אזהרה. האם יש פרוייקט אחר שמממש פונקצינליות דומה, עם יותר הורדות? 

אם כן, נשאל את עצמנו למה? 

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

נוכל לבדוק את רמת הפופולריות של הפרוייקט על ידי מבט על גרף ההורדות שדיברתי עליו מקודם (אני תמיד בודק עם הבור של חג המולד שם 😅😉).
נוכל גם לבדוק את כמות הכוכבים בגיטהאב, ובכללי מבט על הסרגל הזה יכול לתת לנו מושג קטן.
אביא דוגמא מvue.js אהבתי הראשונה-

 

תחזוק- האם הספרייה מתוחזקת? תוך כמה זמן לוקח לתורמי הקוד הפתוח לענות ל issues, כמה pr פתוחים יש, תוך כמה זמן מתייחסים אליהם ובאיזה דרך.

 

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

 

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

במקרה כזה, ובכלל, כדאי לשקול…

שימוש בכלים אוטומטיים שעוזרים לבחון את החבילה

 

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

שירות כמו snyk יכול לעצור את תהליך ההעלאה לproduction כשצריך.

אמנם השירות הוא בתשלום, אבל היי, סניק גם מציע כלי חינמי לבדיקת חבילות npm.

https://snyk.io/advisor/

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

בקיצור שווה בדיקה.
אגב, ישנם כנראה עוד הרבה אלטרנטיבות לsnyk, אני מציע את מה שאני מכיר
מוזמנים לבדוק

תכנון נכון פותר המון

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

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

כך אנחנו חוסכים בתלות שיש לנו כלפי חבילה כלשהי.

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

יש לכם דרכים אחרות לפתור את הבעיות או שלדעתכם פיספסתי משהו?
מכירים אלטרנטיבה לsnyk שממש כדאי לי להכיר?
אשמח אם תכתבו לי את הערותיכם בתגובות..
ואם אהבתם את הפוסט, אודה אם תשתפו תגיבו או תתנו לייק..

קישורים

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

 

וזה הפרק של frontendland בו מתארח גיל תייר שהזכרתי במהלך הפוסט - קישור.
​