תכנות ללא בדיקות

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

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

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

הבעיה היא שהפיתוח עבור אסטריסק גובל לפעמים במגיה שחורה, והרבה "מזל". טוב אני כמובן מקצין את המצב אבל הפיתוח עבורה ממש לא פשוט. בברירת מחדל יש שפה בשם Asterisk Dialplan שגורמת לשפת QBasic להראות ממש ידידותית למתכנת. היא שפה מאוד מופשטת, אשר בנויה מאפליקציות אשר מעבירים להם פרמטרים. אין תכנות פרוצדורלי במובן הרשמי שלו, אם כי יש מאקרויים שניתן לכתוב, ובשביל להגיע למקומות שהם לא מתחת ממש לשורה שמעל, צריך לקפוץ (עם goto) או לשורה המדוייקת או לתווית (label). זה אומר במילים אחרות שכל שינוי עבור ה dialplan של לפעמים פקודה אחת, יכולה לשבור לגמרי את כל מה שיצרנו, והלוגיקה צריכה להשתנות לחלוטין, רק בגלל שרצינו לפעמים להתייחס לעוד משתנה חדש, או רק לעוד תוכן של אותו משתנה.

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

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

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

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

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

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

2 מחשבות על “תכנות ללא בדיקות

  1. elcuco

    ואתה שכחת את הבעייה הכי גדולה – הבורות של הלקוחות שלך.

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

    בהתחלה דיברו עם ה-CTO שמצא את הבעייה. שבוע אחרי זה, פנו אליי וניסו להסביר לי את הבעייה, כדי שאני אפתור (בלי לדעת שכבר נמצא האשם – ה-ISP) כאילו שאני יכול לפתור בעייה שך ה-ISP וה-CTO שלי לא… כן בטח.

  2. ik_5 מאת

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

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

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

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s