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

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

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

התשובה מורכבת בדרך כלל מלפחות אחת מהתרוצים הבאים :

•  לא היה זמן לבדוק את הכל
• תיקנו רק משהו קטן ובדקנו אותו נקודתית

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

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

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

נכתב די הרבה בזכות ביצוע unit test ותהליך test-driven-development ולכן לא אחזור על כל התאוריה.

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

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

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

לתבנית שבה כותבים את הבדיקות קוראים gherkin. זו למעשה Domain Specific Language לתיעוד ההתנהגות הרצויה של תוכנה מבלי להכנס לפרטים של כיצד תסריטים אלו מבוצעים. כמו הרבה דברים טובים בעולם התוכנה היא הגיעה מקהילת הruby. הכלי הנפוץ ביותר ביותר נקרא cucumber. מכיוון שאני כותב את האפליקציה בpython חיפשתי כלי בשפה זו. שוב ישנן מספר אuפציות אני בחרתי ללכת עם behave שנראתה לי הבשלה ביותר.

הרבה מהדברים בוודאי מוכרים לכל מי שקרא את הagile manifesto. אבל כל מי שניסה לממש אג’ייל יודע כמה זה מסתבך כשמגיעים לביצוע. כאן זה יצא כתוצר לוואי.

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

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