לפתור בעיה בלתי פתירה

אסייג ואומר שמאמר זה מיועד בעיקר למתחילים אבל גם מתכנתים וותיקים יכולים למצוא בו עניין. פעמים רבות אנחנו נתקלים בבעיה בעבודה שבמבט ראשון נראית בלתי פתירה. אני אישית, אני מאמין שההבדל בין מתכנת טוב למתכנת מעולה הוא ביכולת לעקוף ולמצוא פתרונות שלא נפתרים באמצעות ההגיון הפשוט. אני לא מדבר על אלגוריתם מסובך או קוד שלא רץ כראוי – בשביל זה יש מספיק כלים ומתודולוגיות. אני מדבר על מצבים שבדרך כלל לא נמצאים בשליטתנו.
דוגמא: אתה מפתח מול שרת אפליקציות ובשלב כלשהו כל נסיון להעלות את האפליקציה (Deploy) זורקת שגיאה: The server failed to deploy the application: error #4522
אתה בטוח שלא עשית שום דבר חריג, אין שום דרך לדבאג את זה ואין שום שינוי בקוד שיכול לתקן את זה. האפשרות הסבירה ביותר למרבית האנשים היא לפנות למישהו מנוסה "תותח" כמו שאוהבים לכנות אותם שיפתור את הבעיה. אתה תצא בסדר: זה לא באג בקוד שלך ולא עשית שום דבר רע. אבל האם שאלת את עצמך פעם איך עובד כלשהו הגיע למצב שהוא נחשב "תותח"? למה שלא תהיה אחד כזה בעצמך?
כמובן שמרכיב הניסיון הוא חשוב אבל יש עוד דברים שמשפיעים על יכולת פתרון בעיות. יש מתכנתים שאחרי שנתיים נחשבים למומחים ויש אחרים שגם אחרי 10 שנים נשארים בינוניים. להלן סדר פעולות שיכול לסייע בפתרון של כל בעיה:

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

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

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

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

חיפוש בגוגל ובאינטרנט
יעיל במיוחד בעבודה מול מערכות חיצוניות. העתק את שורת השגיאה ותריץ בגוגל. בהרבה מקרים ה2-3 תוצאות הראשונות יתנו הסבר מדויק של הבעיה ופתרונה. לפעמים צריך קצת להוסיף מילים לשורת החיפוש כמו: "deployment error #333 WebLogic 8.1" אבל העניין ברור. 20 שניות שיכולות לחסוך שעות של עבודה.
אגב, בדרך כלל חיפוש בגוגל יעיל יותר מחיפוש באתר החברה. גוגל פשוט מאנדקס את העמודים בצורה הרבה יותר יעילה ממרבית מנועי החיפוש הפנימיים. נסו לחפש מידע בגוגל לעומת MSDN או האתר של אורקל ותמצאו שגוגל נותן תוצאות הרבה יותר טובות. רק אם לא מוצאים בגוגל כדאי לחפש באתרים אחרים דבר שבדרך כלל לוקח יותר זמן.

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

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *