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

מתחילים בשאלה של המשתמש

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

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

מבדילים בין תחושה למדידת ביצועים

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

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

בוחנים תאימות לפני שמכריזים על שדרוג

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

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

מגדירים מה פירושו של שיפור משתלם

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

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

משאירים את הידע בתוך הצוות

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

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

ניסוי קטן שמספק תשובה גדולה יותר

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