על אמנות ביצירת תוכנה – Software Craftsmanship

לאחרונה חתמתי על המניפסטו של Software Craftsmanship.

הקדמה

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

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

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

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

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

האומנות ביצירת תוכנה, מה זה?

Software Craftsmanship היא מעבר לכול גישה או פילוסופיה, יש לה המון נקודות משותפות עם xp (extreme programming), אבל כפי שכבר אמרתי, זוהי לא מתודולוגיה, היא לא מגדירה עקרונות low level בפיתוח תוכנה כמו tdd או refactoring.

ישנו ספר שעוסק בנושא, אני מאוד ממליץ על קריאה שלו: הנה לינק אליו

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

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

ממשיכים…

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

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

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

ממשיכים…

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

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

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

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

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

רגע רגע, אני מתכנת .net, זה רלוונטי לי?

הממ, האמת היא שחשבתי הרבה על זה, בכול הפוסטים שמדברים על זה מדברים על זה שאין שום טכנולוגית open source שלא מתאים להחיל עליה softwre craftsmanship.

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

יש לי צוות של 20, האם אני יכול להגיד שהם עובדים תחת הכללים של software craftsmanship?

לא

האמת, לא

ושוב, לא

כאן, אני מסכים לגמרי עם מי שכתבו את הmanifesto, מדובר על צוותים קטנים בהם יש 1-2 craftsman ועוד 3-4 מתמחים, העבודה בצוותים קטנים מאפשרת להדגיש את העקרונות הנחים בצורה טובה יותר, אין שום בעיה ש20 איש יעבדו כך, אבל הם צריכים להיות מחולקים לצוותים קטנים יותר עם מספר מומחים קטן ומספר מתמחים גדול יותר בכול צות פיתוח קטן.

מה הקשר לדוד בוב?

uncle bob (חפשו בגוגל, אל תהיו עצלנים) הוא אחד הspeakers הטובים ביותר שיש לנו בתחום, הוא הגדיר את הפילוסופיה כ"חזרה לבסיס" או "לעשות את הבחירות הנכונות". בוב אגב, הוא הכותב של הספר clean code (עוד המלצה).

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

סיכום

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

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

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

One thought on “על אמנות ביצירת תוכנה – Software Craftsmanship

כתיבת תגובה

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

*

תגי HTML מותרים: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>