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

<בטרוף>

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

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

[חליפה] לא משנה מה. עוד כמה זמן זה ייקח.

[מפתח] אני יהיה להעריך, אבל לא יותר מאשר כמה שעות

(שתיקה, היזם יכול להגיד על זה הולך כמו נאד בכנסייה)

[חליפה] האם היישום כרגע עבודה?

[מפתח] בטח, אבל זה יגדיל את האמינות של התוכנה, כך יכול להיות חשוב לקחת בחשבון.

[חליפה] אבל זה עובד עכשיו נכון?

[מפתח] עבודה לא משווים את האמינות או חוסן.

[החליפה] אם זה עובד, אתה צריך להתחיל לעבוד על הדרישה הבאה.

[מפתח] (בזרועות מורמות) בסדר!

אז זו הסיבה הראשונה שאני חושב DBC מעולם לא תפס, למרות שזה רק טבעי.

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

שלישית, אנשים לא מבינים כי אתה יכול לעשות חוזה עיצוב מונע (CDD) עם TDD. אתה יודע, זה אפשרי.

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

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

אוף, סיימתי לכתוב על זה.

</ Rant>

הודעות קשורות:

1. WebPart תכנות חוזה (Design by Contract)
2. 15 דרכים / שאלות חלקה של SharePoint חוזה
3. 10 צעדים צבאי SharePoint חוזה
4. Spec # עבור SharePoint פיתוח (DBC)
5. IT חוזה דרושים | Sharepoint מהנדס תשתיות | ברקשייר ...

מאמר או מחקר הגישו תחת כללי (אישי) | SharePoint פיתוח.

2 תגובות »

1. 

   וואו. אני חושב שאני עדים השיחה הזאת. כן, חליפות = רע.

   תגובה על ידי Chooklay - 27 ביוני, 2007 @ 4:25

2. 

   כן, אתה די לא

   תגובה על ידי אדם Buenz - 2 ביולי, 2007 @ 11:57

RSS Feed להערות על זה לכתוב. TrackBack-URL

השאירו תגובה