Posts tagged ‘Unit tests’

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 תבחרו את התזמון הנכון והמשימה הנכונה בכדי שהוא יסכים לפחות להתנסות בכך.