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