איך דואגים שהבאגים יתגלו הרבה לפני האינטגרציה?

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

כותבים ספריות.

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

אז למה אני מתכוון?

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

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

כתיבה כזו מגבילה אותנו, ארכיטקטונית וטכנית, באספקטים רבים.

ארכיטקטונית:

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

טכנית:

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

נסו את זה בבית.

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

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

מודעות פרסומת

אודות מייק

תוכנה היא מדע או אומנות?

פורסם ב-17 בנובמבר 2011,ב-כללי. סמן בסימניה את קישור ישיר. השארת תגובה.

להשאיר תגובה

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

הלוגו של WordPress.com

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

תמונת Twitter

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

תמונת Facebook

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

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

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

מתחבר ל-%s

%d בלוגרים אהבו את זה: