4 צעדים שישפרו את תפיסת האיכות שלכם

מתמודדים עם עומס הולך וגדל של דרישות מצד לקוחות? הנה 4 פרקטיקות שכדאי לכם לאמץ על מנת לעמוד בקצב הדרישות הגובר תוך כדי בניית מערכת איכותית

צילום/ תמונה: pexels

מאת ישראל אמינוב, VP Engineering בחברת Flywire

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

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

בכל שלב פיתוח ישנן פרקטיקות חשובות שכדאי לאמץ על מנת לעמוד בקצב הדרישות הגובר תוך כדי בניית מערכת איכותית:

#1 מוצר פשוט – Simple Product

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

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

MVP = Minimum Viable Product
רעיון או דרישה יכולים מהר מאד לגדול להגדרה רחבה ומקיפה. בשלב הזה, גם אם יש דרישה מהלקוח, איננו יודעים כמה מתוכן ההגדרה חשוב, או עד כמה הרעיון יתפוס אצל המשתמשים. כמו כן, סביר שפיתוח של דרישה גדולה ומורכבת יוביל למערכת מורכבת ותחזוקה יקרה. אם נרצה לשנות את הדרישה בהתאם לביצועים אצל הלקוחות או נבין שיכולות מסוימות היו מיותרות, השינוי יהיה יקר וכנראה ישאיר אותנו עם פונקציונליות ותשתיות סבוכות ומיותרות במערכת.

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

#2 פיתוח אינקרמנטלי – Incremental Delivery

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

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

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

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

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

בפיתוח אינקרמנטלי ׳שוברים׳ את הפרויקט למשימות קטנות וניתנות לדחיפה למערכת החיה: משימות שמשכן 1 עד 3 ימי עבודה, הניתנות לבדיקה באופן עצמאי ואינן תלויות במשימות אחרות על מנת לדחוף את השינוי שלהן למערכת החיה.

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

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

צילום/ תמונה: pexels

#3 CI/CD

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

CI = Continuous Integration

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

אימוץ מלא של תהליך CI והשפעה רחבה שלו על האיכות יתרחשו בשילוב עם התהליכים הבאים: אימוץ תהליך הפיתוח האינקרמנטלי, הרחבת כיסוי קוד קיים וקריטי בבדיקות אוטומטיות והגדרת סיום של כל משימה (Definition of Done) כך שתכלול הוספה או שינוי של בדיקות אוטומטיות.

CD = Continuous Deployment

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

במצב בו יש CI, ההמלצה היא לדחוף את השינוי רק במידה שהשינוי עבר את ה-CI (כלומר, כל הבדיקות האוטומטיות הרלוונטיות עברו).

שתי יכולות חשובות ומשלימות שמומלץ לפתח לצד CD הן Hot fix ו-Rollback/Revert.

Hot fix משמשת במקרים דחופים וקריטיים המצריכים העלאה מהירה של תיקון למערכת החיה התקולה, כדי שתהיה אפשרות לעקוף את ה-CI ולא להריץ בדיקות.
Rollback/Revert משמשת למקרים דחופים בהם נמצאה תקלה חמורה במערכת החיה כתוצאה משינוי שנדחף. היכולת מאפשרת לבטל את השינוי ולחזור גרסה אחת אחורה בקוד (revert) או לגרסאות ישנות המותקנות במערכת החיה (rollback).

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

#4 ניטור מערכת

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

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

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

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

הכתבה בחסות Flywire

Flywire מאפשרת לחברות מכל העולם לפשט את תחום התשלומים עבור לקוחותיהן. כחברה צומחת בתחום הפינטק, Flywire מובילה את תחום הדיגיטציה של התשלומים ומאפשרת ללקוחותיה לספק מענה מתקדם ללקוחותיהם - מהיר יותר ובתנאים שלהם. החברה מלווה ארגונים המספקים שירותים בתחומים קריטיים בחייהם של לקוחות הקצה כמו בריאות, השכלה גבוהה, טכנולוגיה ועוד.
החברה מספקת שירות 24/7, ובמסגרתה בוצעו עסקאות בהיקף של כ-12 מיליארד דולר. עד היום גייסה החברה 260 מיליון דולר מגופים מובילים, היא מחזיקה 11 משרדים במדינות שונות בעולם. לחברה מרכז פיתוח בישראל המבוסס על רכישה של חברת סטרט-אפ ישראלית. מרכז הפיתוח בישראל אחראי על תשלומים בתחום הבריאות ונמצא בתהליך גדילה.

Avatar

כתב אורח

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

הגב

הגב ראשון!

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

wpDiscuz

תגיות לכתבה: