פרספקטיבה של מדען נתונים
קוד פתוח הוא רעיון כל כך מדהים! על ידי צירוף המקורות, הכישורים והידע של קהילה שלמה, ניתן ליצור כלים שלא היינו יכולים ליצור בנפרד. הכלים שיוצאים משיתופי הפעולה הללו הם באמת יותר מסך חלקיהם.
כתוצאה מכך, אנו מדעני הנתונים משתמשים בתוכנה הזמינה באופן חופשי שמניעה כל כך הרבה טכנולוגיות, ועדיין יש לנו הזדמנות להיות מעורבים בפיתוח שלה.
במהלך השנים האחרונות, התמזל מזלי להיות מעורב בקוד פתוח והייתה לי ההזדמנות לפתח ולהפעיל מספר חבילות!
פיתוח קוד פתוח הוא יותר מסתם קידוד
במהלך הזמן הזה, היו הרבה מכשולים שצריך להתגבר עליהם ולקחים שאפשר ללמוד. מתלות מסובכת ובחירות עיצוב API ועד לתקשורת עם בסיס המשתמשים.
עבודה על קוד פתוח, בין אם ככותב, מתחזק או מפתח, יכולה להיות מרתיעה למדי! עם מאמר זה, אני חולק כמה מהחוויות שלי בתחום זה, אשר בתקווה יעזור למי שרוצה לפתח קוד פתוח.
כאשר אתה יוצר תוכנת קוד פתוח, אתה בדרך כלל לא מכין את החבילה רק עבור עצמך. משתמשים, מכל סוגי הרקעים השונים, יעשו שימוש בתוכנה שלך. תיעוד מתאים עוזר לאותם משתמשים להתחיל בהרבה.
עם זאת, אל תזלזל בהשפעה שיכולה להיות לתיעוד על השימושיות של החבילה שלך! אתה יכול להשתמש בו כדי להסביר אלגוריתמים מורכבים, לתת הדרכות מקיפות, להציג מקרי שימוש ואפילו לאפשר דוגמאות אינטראקטיביות.
במיוחד תוכנה הקשורה למדעי הנתונים יכולה להיות קשה להבנה כאשר היא כוללת אלגוריתמים מורכבים. ההתקרבות להסברים האלה כמו סיפור עזרה לי לעתים קרובות להפוך אותם ליותר אינטואיטיביים.
תאמין לי, כתיבת תיעוד טוב היא מיומנות בפני עצמה.
יתרון נוסף הוא שכתיבת תיעוד מוצק מורידה את הזמן המושקע בבעיות. יש פחות סיבה למשתמשים לשאול שאלות אם הם יכולים למצוא את התשובות בתיעוד שלך.
עם זאת, יצירת תיעוד היא יותר מסתם כתיבתו. הדמיה של האלגוריתם או התוכנה שלך עושה הרבה מאוד את זה לאינטואטיבי. אפשר ללמוד ממנו לא מעט ג'יי אלמר כאשר אתה רוצה לדמיין עקרונות אלגוריתמיים בתיעוד שלך. ההדמיות שלו אפילו הגיעו לרשמית מטומטם תיעוד!
בסיס המשתמשים שלך, הקהילה, הוא מרכיב חשוב בתוכנה שלך. מכיוון שאנו מפתחים קוד פתוח, ניתן לומר בבטחה שאנו רוצים שהם יהיו מעורבים בפיתוח.
על ידי שיתוף פעולה עם הקהילה אתה מפתה אותם לשתף בעיות ובאגים, אבל גם להציג בקשות ורעיונות נהדרים לפיתוח נוסף! כל אלה עוזרים ליצור משהו עבורם.
קהילת הקוד הפתוח היא באמת יותר מסך חלקיה
תכונות ליבה רבות ב-BERTopic, כמו דוגמנות נושאים מקוונת, יושמו מאז שהם התבקשו מאוד על ידי המשתמשים שלו. כתוצאה מכך, הקהילה די פעילה והייתה לעזר אדיר באיתור בעיות ופיתוח תכונות חדשות.
בין אם החבילה שלך תשמש מיליוני פעמים או רק כמה פעמים, יצירת אחת היא הזדמנות מצוינת ללמוד עוד על קוד פתוח, MLOps, בדיקות יחידות, עיצוב API וכו'. למדתי יותר על מיומנויות אלה בפיתוח קוד פתוח ממה שהיה לי בעבודה היומיומית שלי.
יש גם הזדמנות למידה ענקית מאינטראקציה עם הקהילה עצמה. הם אלה שאומרים לך אילו עיצובים הם אוהבים או לא. לפעמים ראיתי את אותה בעיה צצה כמה פעמים במהלך כמה חודשים. זה מצביע על כך שעלי לחשוב מחדש על העיצוב מכיוון שהוא לא היה ידידותי למשתמש כפי שציפיתי!
נוסף על כך, פיתוח פרויקטים בקוד פתוח נתן לי את ההזדמנות לשתף פעולה עם מפתחים אחרים.
עבודה על פרויקטים משלך בקוד פתוח מחוץ לעבודה אכן מגיעה עם החסרונות שלה. בעיני המשמעותי ביותר הוא שתחזוקת החבילה, מענה על שאלות והשתתפות בדיונים יכולה להיות די הרבה עבודה.
זה בהחלט עוזר אם יש לך מוטיבציה מהותית, אבל זה עדיין לוקח לא מעט זמן כדי לוודא שהכל מתקיים ביחד.
למרבה המזל, אתה יכול לפנות לקהילה שלך כדי לעזור לך במתן מענה לשאלות, הצגת מקרי שימוש וכו'.
במהלך השנים האחרונות, למדתי להיות קצת יותר רגוע כשזה מגיע לשבירת שינויים. במיוחד כשזה נוגע לתלות, לפעמים יש כל כך הרבה שאתה יכול לעשות!
לדעת באיזו תדירות נעשה שימוש בחבילה שלך היא עזרה עצומה בהבנת עד כמה היא פופולרית. עם זאת, רבים עדיין משתמשים בכוכבי Github כדי להשוות חבילה לאיכות ופופולריות.
בתור מדעני נתונים, עלינו להבין תחילה מה בדיוק אנחנו מודדים. כוכבי GitHub הם לא יותר ממשתמש שנותן כוכב לחבילה. זה אפילו לא אומר שהם השתמשו בתוכנה או שהיא באמת עובדת!
מבחינה טכנית, אני יכול לשלם לאלף אנשים כדי לסמן את המאגרים שלי. במקום זאת, אני מתמקד במגוון סטטיסטיקות, כמו הורדות ומזלגות, אבל גם במספר הבעיות שאני מקבל על בסיס יומי.
לדוגמה, זה נהדר אם החבילות שלך מוצגות חדשות האקר אבל זה לא אומר לך אם הוא נמצא בשימוש עקבי.
כפסיכולוג, אני נוטה להתמקד הרבה בעיצוב החבילות שלי. זה כולל דברים כמו תיעוד ומדריכים, אבל זה אפילו מתורגם לאופן שבו אני מקודד.
הקפדה על כך שהחבילה קלה לשימוש ולהתקנה הופכת את האימוץ להרבה יותר פשוט. במיוחד כאשר אתה מתמקד בפילוסופיות עיצוב כמו מודולריות ושקיפות, חלק מהחבילות הופכות לפיצוץ בשימוש.
נטילת נקודת המבט של פסיכולוג תוך פיתוח תכונות חדשות הפכה את זה הרבה יותר קל לדעת במה להתמקד. מה המשתמשים מחפשים? איך אני יכול לקודד בצורה שמסבירה את האלגוריתם? מדוע משתמשים בעצם משתמשים בחבילה זו? מהם החסרונות העיקריים של הקוד שלי?
הקדשת הזמן להבין את המשתמש הממוצע מניע את האימוץ
כל האמור לעיל מוביל לרוב לכלל בסיסי אך חשוב;
שמור את זה סופר פשוט
באופן אישי, אם קשה לי להתקין ולהשתמש בחבילה חדשה, יש סיכוי נמוך יותר שאאמץ אותה בזרימת העבודה שלי.
אם אתה, כמוני, נלהב מבינה מלאכותית, מדעי נתונים או פסיכולוגיה, אתה מוזמן להוסיף אותי לינקדין או עקוב אחריי טויטר. אתה יכול גם למצוא חלק מהתוכן שלי באתר שלי אתר אישי.
כל התמונות ללא קרדיט מקור נוצרו על ידי המחבר
6 לקחים שלמדתי מפיתוח פרויקטים בקוד פתוח שפורסמו מחדש ממקור https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 דרך https://towardsdatascience.com/feed
<!–
->
