Posts tagged ‘software craftsmanship’

יום העצלנות הבינלאומי

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

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

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

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

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

ולכן אני מכריז כאן ועכשיו על… (תופים בבקשה)

יום העצלנות הבינלאומי

ביום זה כל פועל ופועלת (לפחות בתחום ההיטק) מצווים לחדול מהעיסוק היומיומי השגרתי של כתיבת קודביצוע בדיקותכתיבת מסמכים וכו’

ביום זה ימצאו האנשים דרכים לשיפור מדדי העצלנות בארגון.

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

כל המשתתפים ביום זה יקבלו תעודת הוקרה והסמכה רשמית ממני.

image

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

לסיום דוגמאות לעצלנות קלאסית:
– במקום לבצע חלק ניכר מהבדיקות באופן ידני כל פעם מחדש, לכתוב אוטומציה שמבצעת זאת בשבילכם בזמן שאתם משחקים ברשת באתרים כגון http://www.escapegames24.com/
– במקום לכתוב מסמכים שמתעדים את הקוד ואת הדיזיין, להשתמש בכלים שעושים זאת עבורכם כגון JavaDoc.
– במקום לכתוב כל פעם קוד חדש מאפס, להשתמש בסיפריות שנכתבו כבר ובדוגמאות, ניתן להיעזר באתרים כגון http://stackoverflow.com/

יאללה, לכו לנוח.

Software Craftsmanship – מפגש 7

כבר נדוש לומר, אבל גם הפעם היה ממש ממש טוב!
זה פשוט הולך ומשתפר, שאפו גדול לאורי!

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

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

במרכז המפגש היו שני נושאים:
– שפות דינאמיות מול שפות סטטיות.
– DSL’s.

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

ההרצאה השניה היתה בנושא DSL והעברה ע”י דרור הלפר מ-Better place.
דרור הסביר בקצרה מה זה DSL והציג את הסוגים השונים הקיימים.
בהמשך הוא נתן דוגמא יוצאת מין הכלל לדעתי ל-DSL: הנה היא לפניכם:
The next release candidate would contain features X, Y & Z and no more than five high priority Bugs and no show stoppers

22032011455

זו דוגמא לשפה שכנראה אם אתם קוראים את הבלוג שלי אתם מבינים, אבל למישהו שלא מהתחום זה עלול להיראות סינית -  זה DSL.
החלק השני של ההרצאה של דרור הוקדש ל-Fluent interface.הוא נתן דוגמאות מתוך Mocking frameworks שהבהירו בצורה טובה את הנושא.
ניתן לגשת לשקפים של המצגת ואפילו לוידאו שלה.

 

 

החלק השלישי היה כרגיל עבודה מעשית: התבקשנו לממש DSL למערכת של חוקים עבור עגלת קניות, החוקים הם בסגנון הנחות ומבצעים שונים:
– 1+1 למוצר מסוים.
– קניתה מוצר X קבל מוצר Y ב-15% הנחה.
– ללקוח VIP מגיע הנחה מסוימת קבועה.
– וכו’

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

מצפה בקוצר רוח למפגש הבא.

Software Craftsmanship – מפגש 6

הפעם באמת יצאתי מאוכזב, מאוכזב מאוד אפילו.
לא יכול להיות שפעמיים רצוף אני לא זוכה בהגרלה! לטעמי יש פה אפילו חוסר תום לב מצד המארגנים… אורי 07022011437לטיפולך :)

ועכשיו ברצינות: היה ממש ממש כיף.

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

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

אחרי אורי עלה איתי ממן.
איתי הוא מתכנת (הוא טען ש”לא אוהב את המונח מהנדס תוכנה”) ומרצה בטכניון, איתי בעצם ביצע בשידור חי ותוך הסברים רהוטים Refactoring לקוד של פונקציה בעלת כ-150 שורות אם אינני טועה, עם רמת כינון של 6 או 7, עם שמות משתנים נוראיים, בקיצר אם להתנסח בעדינות – קוד לא טוב.

איתי בחר בגישה שאני אישית מתחבר אליה מאוד והיא לבצע Refactoring מבלי לנסות להבין את ההתנהגות אלא לפרק את הקוד לחלקים קטנים יותר ורק אח”כ לנסות להבין מה כתוב שם
זה אומר למשל לקחת בלוקים שלמים ולנסות להוציא אותם לפונקציה – Extract Method ולחזור על הפעולה.
וכמובן שאין צורך לציין (אז למה אני מציין?) שהוא השתמש ב-Rename.

07022011444 בנוסף איתי גם הראה טכניקות לביצוע שיפורים בקוד שהן לטעמי לא עונות לגמרי על ההגדרה של Refactoring מכיון שהן משנות את ההתנהגות של הקוד ולא רק את צורתו.
למשל טכניקה שאיתי הראה היא לשנות רמת כינון של מתודה ע”י ביצוע של Early exists במקום if-else.
הוא פישט תנאים מסוימים, הוא הזיז מיקום של משתנים וכו’, לא שזה רע, להיפך. אבל זה לא בדיוק refactoring.
ולמען התזכורת Refactoring זה :
x+1)*(x-1) = x2-1)

איתי העביר את ההרצאה בצורה מעניינת, זורמת ופתוחה. כל הכבוד!

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

באופן כללי מאוד נהנתי ואני כבר מצפה למפגש הבא.

מה יוצא לי מ-Unit tests ?

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

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

clip_image002[2]שיפור קורות החיים – אם אתם עובדים באותה תעשיה כמוני, ישנו סיכוי לא רע שלכל היותר בתוך 4 שנים מהיום תעבדו בחברה אחרת, ואפילו סיכוי טוב יותר שהחברה האחרת הזאת, כאשר תגייס עובדים, כנראה תבקש לראות שיש לכם ידע וניסיון בכתיבת בדיקות אוטומטיות, אבל לא סתם ראיתם-הכרתם, אלא ניסיון ממשי. אז אם אתם רוצים להשאיר לעצמכם סיכוי למצוא עבודה בחברה טובה ורצינית כדאי לכם להתחיל ללמוד ולהטמיע את הנושא.
Unit tests = בטחון תעסוקתי.

הערכה טובה יותר ע”י הממונים – כמו שאתם בודאי יודעים, אחד הפרמטרים שלפיו מודדים אותנו (המפתחים) הוא איכות הקוד, כמות הבאגים, ומהירות התיקון, את שילוב כל הדברים האמורים (ועוד) נהוג לכנות מדדי תפוקהפרודקטיביות, אני חושב שדבר טבעי הוא לרצות הערכה טובה יותר של הממונים שלנו, אם נשתמש ב-Unit tests נכון מובטח לנו שתרד כמות הבאגים באופן משמעותי, נגלה את רוב הבאגים עוד לפני שהתחלנו לדבג (debugging), ואתם הבאגים שכבא ימצאו לנו נפתור בזמן קצר הרבה יותר, כלומר, נעלה משמעותית את הביצועים האישיים, נראה לי שזו עסקה שווה לכל נפש,
Unit tests = הערכה גבוהה יותר ע”י ממונים.
ואם זה לא מספיק אז….

משכורת גבוהה יותר – אם נעלה את הביצועים שלנו, נהיה טובים יותר ואיכותיים יותר, הרי שנהיה בעלי ערב רב יותר לארגון שלנו, ואם לא לשלנו אז לארגון אחר. אם אנחנו בעלי ערך גבוה יותר זה בד”כ מתבטא בתלוש המשכורת שלנו.
Unit tests = משכורת גבוהה יותר.

בואו נחבר את המשוואה:
Unit tests = בטחון תעסוקתי + הערכה + משכורת.

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

אבל… זה כמובן לא מספיק, כי השאלה היא “בשביל לקבל את כל התועלת הזאת, כמה עליי להשקיע?”, וזו שאלה טובה, אבל התשובה היא טובה לא פחות: השקעה נמוכה מאוד, ללמוד את הבסיס לוקח לכל היותר יום (מה כבר צריך ללמוד? מה זה Assert?),
ספריות ה-Unit tests השונות הן בד”כ עם ממשק קריא פשוט ואינטואיטיבי, הזמן שלוקח לכתוב בדיקה בודדת הוא בד”כ דקות בודדות, אז מה רע?
יש שיטענו שהכתוב לעיל לא נכון, כתיבת בדיקות לוקחת המון זמן, אם כך כנראה שצריך להראות לאותם אנשים מה הם מפספסים, איזה ידע או הבנה חסרים להם בכדי לכתוב בדיקות קטנות שבודקות דבר אחד בלבד, אולי זה פשוט קשה להם וצריך להסביר להם יותר טוב?
תופעה נפוצה שאני נתקל בא היא שבבדיקה אחת מנסים לבדוק המון, ואז כמובן גם הבדיקה מורכבת ולוקחת זמן, גם קשה לתחזק אותה והיא גם פחות קריאה.
יש מספר חריגים, אתייחס לשניים:
– כאשר כותבים את הבדיקות בסוף שלב הקידוד, הכתיבה שלהן יכולה לקחת המון זמן – אז תתחילו לכתוב בדיקות כבר מהתחלת הפיתוח (אני לא מדבר על TDD)
– כאשר כותבים קוד בתוך מערכת קיימת (legacy) יכולה להיות סיבוכיות ראשונית לנתק את הקוד החדש מהקיים, עם הניסיון גם זה נהיה יותר ויותר פשוט (בד”כ, אבל לא תמיד).

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

Software Craftsmanship – מפגש 5

קודם כל השורה התחתונה: היה טוב! אפילו טוב מאוד.

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

המפגש החל בדברי פתיחה של היוזם והמארגן, אורי לביא, שסקר את הפעילות של הקבוצה ואת התוכניות העתידיות.
השיטה שבה אורגן ההמפגש הזה היא ללא הרצאות פרונטליות, אלא היו שלושה איזורים שכל אחד מהם הוקדש לתחום אחר: DRY, TDD ן-Code review.
התכנון היה שכל אחד מהמשתתפים במפגש אמור לעבור בשלושת התחנות, ואכן כך היה.
אני אפרט בסדר שאני השתתפתי בתחנות.

15122010418התחנה הראשונה היתה TDD.
אני אוהב TDD.
את התחנה הזאת הוביל גיל זילברפלד מ-TypeMock ובתחנה הוא למעשה ארגן סוג של דוז’ו על בסיס קטה מספר 13 שהיא לכתוב מחלקה שסופרת שורות קוד.
לטעמי הוא הנחה אותה בצורה מעולה, ובחצי שעה הוא הצליח להעביר את המסר הבסיסי של TDD, ולחוות את השאלות שעולות תוך כדי כתיבת הטסטים (Unit tests). הוכחה לאיכות של ההנחיה היא כמות הדיונים והשאלות שעלו מהקהל.
אני אוהב TDD כבר אמרתי ?

15122010420התחנה השניה היתה DRY שזה אומר (Don’t Repeat yourself) – מבלי לצלול לעומק (ויש…) DRY הוא עקרון בסיסי בתוכנה (כתיבת קוד, DESIGN, DB וכו’) שטוען (ובצדק) שצריך להשתדל מאוד לא לחזור על עצמך. את התחנה הזו הוביל אביב בן יוסף שעשה עבודה טובה מאוד בלהסביר את הנושא באופן כללי, ואחר כך הציג קטה שמהותה לתרגל את עקרון DRY, בשלב זה התחלקנו לזוגותשלשות וניסינו לעשות את הקטה, היה נחמד מאוד, אם כי בעיות טכניות של רשת ולפטופים בזבזו הרבה זמן, כך שלא הספקנו הרבה.

15122010419תחנה שלישית ואחרונה היתה Code review. קןדם כל שאפו על הרעיון לבצע קוד ריוויו לקוד אמיתי של חברים בקבוצה, ומעבר לכך, שאפו על החברים שטרחו והביאו קוד שהם כתבו כדי שנוכל לעשות עליו קוד ריוויו. את החלק שאני הייתי בו הנחה אורי לביא (להלן היוזם) והוא למעשה הדגים איך הוא מבצע קוד ריוויו בזמן אמת על קוד שמישהו כתב, הוא הסביר עקרונות ואיך כדאי לגשת לקוד של מישהו אחר.
לי אין ספק שאורי יודע לעשות קוד ריוויו!
אני חייב קרדיט קטן לרן תבורי על רעיון מעניין שהוא העלה: רן טען ובצדק, שה-IDE המודרנים גורמים לנו להתעצל מכל מיני בחינות מכיוון שהם מציעים כלים מובנים כגון קפיצה מהירה מפונקציה לפונקציה, Collapse של חלקים וכו’, מה שהוא מציע זה לנסות מידי פעם לכתוב קוד או לעשות קוד ריוויו בעורך טקסט פשוט, זה רעיון מאוד מעניין ואני בטח אנסה אותו בקרוב ואדווח על התוצאות.

אם כל זה לא מספיק אז אורי גם הצליח לארגן “חסות” והגריל שני ספרים ולוח שנה. ללא ספק תוספת נחמדה.

אז באמת היה טוב, אפילו טוב מאוד, מצפה בקוצר רוח למפגש הבא.

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

Software Craftsmanship בישראל

לצערי, ולמרות שרציתי, לא התאפשר לי לקחת חלק במפגשים הקודמים (שניים במספר), אבל… לא אמרתי נואש.
המשכתי לנסות לפנות כמה שעות ביומן – והצלחתי, והנה מצאתי את עצמי מחפש חניה ברחוב הסוללים (ומוצא בקלות), וצועד לכיוון משרדי Checkpoint, שהסכימו ברוב חסדם לארח חבורה של כ-50 חנונים שאין להם דבר טוב יותר לעשות בזמנם הפנוי מאשר לדבר על תוכנה.
איזה כיף !

את המפגש פתח אורי לביא שהוא מנהל R&D ב-PicScout וגם היוזם של המפגשים הללו, הוא הציג את הרעיון העומד מאחורי הקבוצה, והזמין אנשים ליזום הרצאות ונושאים למפגשים הבאים.
בהמשך הוא הציג את ה- מניפסט של S/W craftsmanship.

אחריו דיבר אורי מ-OutBrain והציג יוזמה מעניינת לשיתוף ידע בין אנשים וארגונים בישראל בשם ILTechTalks. הוא הציג מצב שבו “שוברים את הראש בלי לדעת שבדלת ליד יש מישהו שיכול לעזור לנו”.
הרעיון בא לתת פתרון לשאלה “האם יש מישהו שיכול לעזור ב….”, המיזם מרכז את גורמי הידע והרצאות מוקלטות בוידאו (בעברית !!!!), דרך האתר ניתן לבדוק האם יש מישהו שיכול לעזור וליצור איתו קשר ולהזמין אותו להרצאה אשר תצולם ע”י ILTechTalks ותופץ באתר שלהם לרווחת הציבור.

הדבר הבא, ולמעשה החלק העיקרי במפגש היתה הרצאה של ליאור פרידמן בנושא
“Writing better code” (לינק למצגת), במהלך ההרצאה היו הרבה דיונים וויכוחים, דבר שבאופן אישי היה לי מעט קשה – ציפיתי שבקבוצה שששמה Software Craftsmanship יהיה טריוויאלי שיותר משלושה פרמטרים למתודה זה לא רעיון טוב, ציפיתי שכתיבת Test לפונקציה לפני שעושים לה Refactoring יהיה טבעי ממש, אבל… ההרצאה היתה טובה, וליאור הצליח לנווט את הדיונים למקום פרודוקטיבי וחיובי.

image

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

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

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