השפעת עיצוב תוכנה
הוצג| English | משמעות |
|---|---|
| modular/ˈmɒdjʊlə/ | מודולרי |
שני עיצובים מסודרים יכולים לדווח על ממוצעים שונים
- רישום בדיוני מכיל ציונים 80, העדר ו-100. טיפול בהיעדר כאפס נותן
(80 + 0 + 100) / 3 = 60; השמטת התוצאה ההיעדרית נותנת(80 + 100) / 2 = 90. - שיטות נפרדות יכולות לחשב את שתי התוצאות נכון. הארגון אינו בוחר במדיניות הדיווח: יש לקבוע מה משמעות ההיעדר, מי מחליט, ואיזה מכנה הדיווח חייב להציג לפני השימוש בתוצאה.
הציונים הם 80, חסר ו100. על פי מדינת הציון הזמין, מהו הממוצע?
Difficulty 2/5 · 140 coins + a small bonus on first completion today
סכום הציונים הנוכחים הוא 180 ומספר הנוכחים הוא 2, כך שה-180/2 = 90.
הפכו דרישה לחוזה
- ציינו אם היעדר פירושו משימה שנבדקה ולא נענתה, משימה שלא הוטלה, או נתונים שעדיין לא הוזנו. מקרים אלו אינם חייבים לשתף בחוק; הדוגמה הבדיונית מדגימה השלכות ואינה מגדירה מדיניות דירוג לבית ספר.
- גבו את הקלט המקובל, את הטיפול בערכים חסרים ואת התוצאה. אם הכלל הוא "ממוצע ציונים זמינים", לרישום עם כולם חסרים אין ממוצע; דווחו על מקרה זה במפורש במקום להמציא אפס או לחלק באפס.
הפרדה בין אחרויות בבדיקות
- עיצוב מודולרי מפריד בין
readScores,averageAvailableו-printReport. ניתן לבדוק את שיטת הממוצע עם ערכים ידועים ללא קריאת קובץ או לכידת תצוגה מעוצבת. - הפרדה עוזרת כאשר הממשקים נשארים ברורים. שינוי במשמעות ההיעדר עדיין עשוי לדורש שינויים בחישוב, בדיווח ובבדיקות; שיטות קטנות ושמות טובים לבדם אינם מונעים תלות אלו.
בדקו מקרים רגילים וגבוליים
- עבור מדיניות הציונים הזמינים, בדקו ש-[80, היעדר, 100] נותן 90, ציון יחיד 80 נותן 80, ו-[היעדר, היעדר] מייצר את תוצאת "אין תוצאה" המוסכמת. אל תבדקו רק שהתוכנית פועלת.
- החישוב למטה משתמש ב-
nullלערכים חסרים. הוא מחזיר ממוצע כפול ומדחה את המקרה של כולם חסרים. הוא מניח מערך לא-ריק (non-null) של ציונים רגילים; תוקף קלט ודיווח הן אחרויות נפרדות.
public class AverageAvailable {
public static double averageAvailable(Integer[] scores) {
double total = 0;
int present = 0;
for (Integer score : scores) {
if (score != null) {
total += score;
present++;
}
}
if (present == 0) {
throw new IllegalArgumentException("No available scores");
}
return total / present;
}
}
עיצוב מודולרי (חלקים עצמאיים, בעלי שמות ברורים) קל ל… בעיקר
Difficulty 1/5 · 100 coins + a small bonus on first completion today
מודולריות הופכת שינויים לבטוחים וחלקים להישמשים מחדש.
כשמכנסים רבים משתפים באותו שיטה, תיקון השיטה הזו יכול ליישב את כל המכנסים מבלי לערוך העתקות מופיעות.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
נכון: מכנסים משתפים במימוש. הסכם החוזה והשפעות השינוי עדיין צריכים לבדוק.
ניסיון (ביאס) במידע או לוגיקה של תוכנית עלולים לייצר תוצאות לא הוגנות בקנה מידה גדול.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
בחירות עיצוב משפיעות על אנשים אמיתיים — השתמשו במחשבה מי יושפע.
לבדיקת חישוב הממוצע באופן עצמאי מהקלט והתפלט המודפס, איזה עיצוב מפריד האחריות הזו הכי טוב?
Difficulty 1/5 · 100 coins + a small bonus on first completion today
הפרדת החישוב מהקלט והתפלט מאפשרת בדיקות עם ציון ידוע ללא פעולות אלו. סתם קיום שיטות קטנות אינו מבטיח נכונות.
עיצוב תוכנית הוא רק אסתטיקה ואינו משפיע על בטיחות השינוי בקוד.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
העיצוב קובע כמה בטוח ניתן לשנות את התוכנית.
השיטה availableAvailable המוצגת מחזירה אפס לערימה כולה חסרה.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
שגויה: היא דוחה את המקרה הזה עם IllegalArgumentException כי אין ציונים זמינים המגדירים ממוצע.
דווח השפעות על משתמשים מושפעים
- דוח על 90 אמור להציין שהוא ממוצע שני ציונים זמינים מתוך שלוש רשומות, עם תוצאה אחת שאינה קיימת שנותרה מחוץ לדוח. דיווח רק על 90 מטשטש מידע שהקורא צריך להשוות תוצאות.
- סקרו מי עשוי להיות מושפע מהנתונים והמדיניות. חישוב יחודי עשוי עדיין להתعامل באופן לא הולם עם סוגים שונים של העדר; בחרו בדרישות המוסכמות ובדקו אותן והבטיחו שהתוצאה תהיה ברורה למשתמשים.
מודולריות הופכת את המדינית לקלה יותר לבדיקה ולסקירה; היא אינה הופכת אותה לעדפה או מתאימה. הממוצעים 60 ו90 משתמשים במכנים שונים. בחרו ותגלו את הכלל במקום לבחור בשקט כל תוצאה שנראית טובה יותר.
עיצוב טוב או גרוע?
בחירות עיצוב יש להשלכות ממשיות. סדרו כל תוצאה.
הובלת שינוי מדינית דרך העיצוב
- אם הדרישה המאושרת משתנה כך שיעלה משימה שלא בוצעה כערך אפס, עדכו את המכנה, את הדוגמאות הרלוונטיות, את הבדיקות ואת ניסוח הדווח. שימוש חוזר בשיטה הוא מועיל רק כאשר החוזה שלה תואם את המשימה החדשה.
- סקרו בנפרד את היכולת לבדיקה, את הנכונות וההבנה של המשתמש. גבולות ברורים מקטינים סיכון מסוים לשינוי, אך יש still לבדוק קוראים והנחות בסיס משותפות כאשר חוזה השיטה משתנה.
עיצוב התוכנה משפיע על תחזוקה ועל אנשים. הפרדו אחריות כך שתנהגות תוכל להיות נבדקת, הגדירו את מדינית הנתונים הנעדרים, בדקו את מקרים הגבול שלה וגלו את המכנה. אריתמטיקה נכונה ומבנה מסודר אינם מאפשרים בעצמם הקמת מדינית מתאימה.
Match the change to the issue it addresses.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
A modular structure enables checking but cannot choose the right policy by itself.