בפרק החמישי בפודקאסט של Front Cast, אדיר קנדל וניר ארגיל משוחחים יחד עם דוד מאיר לוי על Velocity בפרונט. בעצם, כל צוות פיתוח חייב לשמור על מהירות פיתוח שמטרתה היא להעשיר את המוצר.
בצוותי פרונט מהירות הפיתוח לעיתים נפגעת לכן, החלטנו לנסות ולתקוף את הנושא הזה מכמה כיוונים. יחד נבין כיצד ניתן לשמור על זריזות הפיתוח של הצוות מבלי לפגוע בתקשורת הבינ-ציוותית ובאיכות התוצר.
בירוקרטיה ארגונית
בלא מעט ארגונים מהירות הפיתוח יכולה להיפגע מבירוקרטיה והתהליכים שמנהלים החליטו להכניס לתהליך הפיתוח והעלאה של פיצ׳רים. דוגמא אחת כזו היא החובה לבצע בדיקות A/B לכל פיתוח שצריך להגיע ללקוח. למעשה, הקוד שלנו חייב לפעול רק אצל חלק מכמות המשתמשים כדי לזהות האם ישנה פגיעה בשימוש של המוצר. רק אחרי זמן מסויים, לאחר שהוכח כי הקוד לא גרע מתקינות המוצר ניתן לגלגל אותו לכלל המשתמשים.
חשוב לציין, בירוקרטיה אירגונית אומנם יכולה להאיט את מהירות הפיתוח אך היא לא בהכרח שגויה. בסופו של דבר צריך לשמור על יחס של קוד איכותי אל מול כמות פיתוחים חדשים.
שימוש שגוי בכלים וטכנולוגיות
בחירה לא נכונה של טכנולוגיות בהחלט יכולה לפגוע ב Velocity של הצוות. דמיינו צוות קטן עם מוצר התחלתי שיכול לנוע בזריזות ולעלות פיתוחים חדשים בקצב גבוה. בפועל אותו הצוות מנהל תהליך CI/CD מורכב כתצואה מבחירה שגויה של micro-frontends לניהול הדפים באפליקציה. מה שמעט את קצב שיחרור הגירסאות החדשות למוצר.
״לפעמים כשיש לנו ביד פטיש כל בעיה נראית כמו מסמר״. חשוב להבין את מגבלות הצוות והמוצר לפני הבחירה בכלי כזה או אחר להשגת המטרות. גם אם נראה שכרגע זה לא פוגע, זה תמיד יכול לחזור אלינו כמו בומרנג בעתיד.
קונבנציות
מתכנתים לא מושלמים וככאלה עלינו להכניס כללים וחוקים לפרויקט בכדי לשמור על קריאות וייעול תחזוקתו. אחת הדרכים הטובות ביותר להשגת המטרה הזו היא הכנסת קונבנציות כמו שמות משתנים, פונקציות, טייפים, קבצים ותיקיות. כמו כן, אכיפה של Code styling כמו מתי לשבור שורה וכמות הטאבים או הרווחים בפרויקט.
כל אלה ועוד, מקטינים את כמות השאלות והתהיות של מפתחים ברגע כתיבת הקוד. מה שמשפר את המהירות בה אנו מעלים פיתוחים למוצר.