לאחרונה התחלתי לפתח אבטיפוס לרעיון מסויים למיזם חדש. מדובר על מוצר בתחום המערכות מידע ואני צריך הדגמה שתוכל להמחיש את הרעיון ולהוכיח היתכנות. משהו שאפשר להציג ללקוחות ולמשקיעים ואולי גם לשותפים פוטנציאליים. כיוון שזו לא הפעם הראשונה שאני כותב POC החלטתי לכתוב על זה פוסט בו אפרט כללים וטיפים לכתיבה נכונה.
קוד גנרי או פתרון זמני?
הנושא הראשון שצריך להחליט עליו הוא האם לפתח גרסה שתהווה בסיס למוצר המלא או שמא לפתח גרסה מינימלית שתעבור שכתוב? במחשבה ראשונה חבל לכתוב פעמיים ואם כבר מפתחים אבטיפוס עדיף להשקיע בו כדי לחסוך אחר כך. אך לדעתי זו לא גישה נכונה. להלן הסיבות למה לא להתייחס לאבטיפוס כפלטפורמה למוצר שלם:
- לפיתוח אבטיפוס יש מטרה מסויימת. בדרך כלל זה להצגה בפני משקיעים או לקוחות. לרוב אנחנו לחוצים בזמן ובמשאבים ורצוי להתמקד במטרה. המטרה היא להגיע להדגמה שעובדת בצורה סבירה בתסריט מסויים. כל דבר מעבר לזה רק יעכב ויסית אותנו מהמטרה כך שעדיף לזנוח את המאמצים להפוך את ההדגמה לפלטפורמה להמשך.
- לאחר סקר שוק מעמיק ולאחר כתיבת האפיונים הרבה פעמים מתגלה שמה שחשבנו בהתחלה הוא לא מה שנממש בסוף. חבל להשקיע זמן ומאמץ בפיתוח כשבסוף המוצר ייראה אחרת לגמרי.
כמובן שיש לבחון כל מקרה לגופו. יש מצבים בהם כדאי לפתח "כמו שצריך" במיוחד כאשר בטוחים בתצורה הסופית ואין ספק לגבי המשך הדרך.
להתמקד במינימום ההכרחי
כלל האצבע שמנחה את פיתוח האבטיפוס הוא התמקדות במטרה קצרת טווח. יש לזכור שהפיתוח יימשך תקופה קצרה, יעבדו עליו מספר מועט של אנשים (לפעמים זה רק אתה), ואין כוונות לתחזק אותו בעתיד. הנה טבלת ההמלצות לפיתוח אבטיפוס:
|
רכיב |
המלצה |
|
הערות בקוד |
רק במקרים בהם יש כתיבה יוצאת דופן שעלולה להיות לא מובנת |
|
Log |
אין צורך. המוצר ממילא לא ירוץ בProduction והוא פשוט מספיק כדי לדבאג במקרה הצורך |
|
Unit Tests |
לאנשי הTDD ברור שצריך. לאחרים – מומלץ בדיקות פשוטות בלי Mocks ושאר סביבות מתוחכמות |
|
Integration Tests |
אין צורך |
|
שימוש בFrameworks |
האם להתשמש בפריימורקים כמו SPRING או Hibernate או שמא להסתפק בקוד "רגיל"? במידה ואתה בקיא לחלוטין בסביבה מסויימת והיא יכולה לחסוך זמן בפיתוח זה מומלץ. לעומת זאת, פריימוורק שמתכוונים ללמוד ולהתשמש בו במוצר הסופי לא כדאי להתעכב איתו עבור הPOC. |
|
משתנים Hard coded |
לא צריך להשאיר דברים hard coded כמו מחזרוזות בתוך פונקציות. עדיף להוציא הכל למשתני const. מצד שני אין צורך להוציא דברים החוצה (XML, DB, קובץ) אפשר לשנות את הקוד במידה ורוצים לערוך משהו |
|
OOP |
כללי כתיבה נכונה: חלוקה למחלקות, שכבות, וכו'. אין צורך להשתמש בDP מורכבים או בירושה מוגזמת. יש לזכור שהקוד כנראה יתפרס על פני מחלקות מועטות |