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

איך ניגשים לזה?

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

ברגע שהסברנו לעצמנו את האתגר כדאי ללכת ל AI כדי לשמוע מה כולם עושים. הפרומפט הזה נתן לי תוצאה טובה:

I'm building a TODO editor allowing users to create todos items, edit todos, delete todos and reorder todos in the list with optimistic updates.

When users perform multiple actions before server had a chance to update the system has strange bugs, for example: 

1. trying to edit a todo that wasn't yet created 2. trying to reorder todos when server state is different than the optimistic state

Suggest 4 possible architectures to combine optimistic updates and editing, order from simple to complicated. For each architecture explain what API calls are made and when and how it deals with user editing faster than server updates

ואתם יכולים לראות את השיחה כאן: https://chatgpt.com/share/696e35f8-9d68-8009-a35a-26169c8ccbe9

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

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

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

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

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

4. הנאה - אין הרבה כיף בלכתוב פתרון עם באגים שעובד פחות טוב ממה ש AI היה כותב או להגיד ל AI "טוב תבנה את הדבר הכי פשוט" ולהגיש.

אם אין לכם זמן לכתוב מימוש נכון, איפה תמצאו זמן לכתוב את המימוש פעמיים?