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