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

בחזרה לעמוד ראשי


Code Voodoo
כמה מכם מצאו את עצמם בשיאו של תהליך עליית גרסה / בדיקת תקלה בעת פיתוח / בדיקת תקלה ב-Production אשר במהלכה פולט בנונשלנטיות אחד מחברי צוות הפיתוח - "זה וודו" או יותר טוב מזה "זה בטח המנוע של .Net גורם ל-[הערכה שגויה כלשהי]".

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

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

אז מה אפשר לעשות?

  • תכננו היטב ועצבו (Code Design - ממשקים הם לא הדבר היחיד שאנחנו מעצבים בנטקראפט) את האפליקציה באופן בו יש לכם הבנה מלאה של כלל התהליכים שפועלים בה, אם באופן סינכרוני ואם באופן א-סינכרוני. רמז - תכנון טוב הוא לעתים כזה שמתבסס על פתרונות מוכרים (Design Patterns) וכן כזה שקל לתעד ולתקשר אותו לחברים בצוות.

    דוגמה לתכנון לא טוב:
    then-a-miracle-occurs-cartoon.png

  • לימדו להכיר היטב את הפלטפורמה על-גביה אתם מפתחים, בייחוד את המערכות הפנימיות המרכזיות, הטריקים היידועים ולא-פחות ה-"שטיקים" המוכרים.
  • דאגו שהאפליקציה תספק לכם מידע רב ככל שניתן הן בזמן פעילות תקינה ובפרט בעת קריסות ותקלות שקורות בעת הריצה. צרו מצב ריצה Debug שמאפשר לכם לקבל מידע מפורט על כל פעולה ופעולה בנקודה מסויימת בזמן.
  • השתמשו בכלים המאפשרים המספרים לכם כיצד משתמשת האפליקציה שלכם בגלגלים הקטנים של הפלטפורמה וכן מספקים לכם תובנות על סיכונים ושימושים בעייתיים, דוגמה טובה היא כלי Profiling וכן כלים לניתוח קוד.
  • מיצאו דרך שתאפשר לכם להשתמש בכלי ה-Debug המובנים במערכת ההפעלה, לא תאמינו כמה מידע תוכלו להפיק מהם, באחד המקרים בעבר נתקלנו במצב בו אפליקציה היתה מאתחלת עצמה כל מספר דקות ולמרות שפעלנו לפי כל ההמלצות הקודמות לא הצלחנו לאתר את הגורם לאיתחול היות והוא התרחש בסביבת ה-Production. בסופו של תהליך, ניתוח של Dump בעזרת כלי Debug גילתה לנו ריקורסיה חבויה ברמת דיוק של שורת קוד בקובץ ספציפי.

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

Bookmark and Share


3 תגובות לפוסט ”וודו בקוד? פנה לרופא האלילים הקרוב לביתך“

  1. לפי אופן הצגת הבעיה בפוסט, אולי קל יותר פשוט לא להשתמש בפלטרפומות של מיקרוסופט?

  2. רן,

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

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

  3. ארתור סי קלארק אמר:
    כל באג מתקדם מספיק הוא בילתי ניתן להפרדה מוודו.

לכתוב תגובה

(חובה לפחות לרשום שם!!!)

(...אף אחד לא יראה את זה)

(תפרסם/י את עצמך! שידעו מאיפה את/ה!)