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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הappengine מאפשר שימוש במספר שפות. כשהתחלתי את העבודה היו שתי אפשרויות : JAVA ו PYTHON. היום נתווספו גם PHP ו GO. GO היא שפה נחמדה מבית היוצר של GOOGLE, ועדיין לא נראית לי בשלה עד כדי לבנות מזה מוצר מסחרי. את JAVA אין צורך להציג, ולמרות הפופולאריות שלה אני אף פעם לא הצלחתי להתחבר לסביבת העבודה שהיא יוצרת, עניין של טעם אישי כנראה. השפה היחידה שממש הכרתי מהניסיונות הבייתים שלי לתכנת אתרים (תמיד הקפדתי ללכלך את היידים בעצמי כדי שאוכל להבין מה התכנתים שלי מדברים) הייתה PHP. ולו הייתי מתחיל את הפרוייקט היום כששפה זו אפשרית, יכול להיות שהייתי בוחר בה כדי לחסוך זמן. לשמחתי זו לא הייתה אפשרות ולכן בחרתי בPYTHON. ואני מאוד שמח שכך בחרתי, ושכר הלימוד היה בהחלט שווה את זה.

אז יש לנו שרת ובחרנו שפה. צריך להדליק את הEDITOR ולכתוב “HELLO, WORLD” לא ? אומנם אפשר להשתמש ב(הכנס את שם העורך טקסט החביב עליך) אבל רציתי תמיכה יותר ממנימאלית בשפה, ויכולת שימוש בדיבאגר, אז הבחירה היתה בין pycharm לבין eclipse + pydev. אז למרות שהראשון ממש מוצלח וכאמור אני נרתע מהעולם של JAVA, עניין המחיר דחף אותי לכיוון של הבחירה השניה.

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

כל מי שכתב תוכנה אי פעם, יודע שאין צורך להמציא את הגלגל מחדש (למרות שעדיין לא ראיתי תכנת שקרא קוד של מישהו אחר ולא הכריז “צריך לכתוב את זה מחדש”). במקרה של אפליקציות רשת המרכיב החוזר המשמעותי הוא הweb framework. פייטון מציע מגוון שלם של סביבות עבודה כאלו בכל גודל וצבע. גוגל עצמה מציעה את webapp2 כברירת המחדל, ולכן התחלתי שם. זו מערכת קלת משקל ופשוטה, אך ברגע שהאפליקציה גדלה מעט זה התחיל להרגיש צפוף והרגשתי שאני צריך לעבוד קשה כדי לשמור על הסדר ושדברים יעבדו כשורה. מהצד השני של הסקאלה ישנה את האלופה במשקל כבד django. ג’נגו מעניקה סביבה בשלה ומלאה לתכנת. וחשבתי שיכולת האבסטרקציה שלה תהיה יתרון במידה ואצטרך לעבוד לפלטפורמה אחרת. החסרונות שלה היו עקומת למידה תלולה ובעיות התאמה לבסיס הנתונים של גוגל שבזמנו הציעו רק גרסאת non-relational.

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

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