2 כוסות

כל בדיחה יש בה חלק מהבדיחה. השאר אמת.

בדיחה ישנה וטובה. שואלים - איך מתכנת הולך לישון? הוא שם ליד המיטה 2 כוסות. 1 עם מים ו1 ריק. עם מים - אם אני אתעורר וארצה לשתות. למה צריך ריק? אם אני אתעורר ולא ארצה לשתות.

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

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

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

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

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

כאן בדיוק בא הקטע מהמשל. ישר חשבתי – הבחורה מאפיינת, עובדת מלא עם שאילתות. היום זו שאילתא אחת, מחר היא תרצה 2, 3, 5 – לך תדע. היום אכפת לה רק משם הקובץ, מחר – שמות לגליונות (למרות שהדגישה כל הזמן – "לא, מה פתאום, ממש ממש לא, משהו פשוט ומהיר". אה, וכל השאילתות – למרות טענתה על מס' שורות בודדות עלולות פתאום לגדול לכמות רבה מזו.

טוב, בלי להלאות במדי פרטים – במקום שעה לקח לי מספר ימים טובים לפיתוח. אבל, וזה אבל גדול, יצא מזה: פיתחתי רכיב DLL, שיודע לקחת בבת אחת מס' שאילתות, להעביר את כולם בבת אחת (ללא לופ) לאקסל בצורה כמעט מיידית, לתת שמות לגליונות, לעשות זאת באופן גלוי (עם פתיחת תוכנה) או סמוי. יתירה מזו, הוספתי גם אפשרות לעבודה ללא ממשק כלל, דרך CommandLine עם פרמטרים  (טוב, פיתוח החלק הזה לקח לי עוד זמן מה בנפרד – אבל לבצע אותו היה כבר הרבה יותר פשוט מאשר לשנות מבנה פנימי של הקלאס, היות וכבר הייתי ערוך לכך). והעיקר, שלא רק שהבחורה אכן לאחר מס' שבועות בודדות חזרה אלי עם בדיוק אותן הדרישות (ואמרתי לה שכבר הכל עובד בדיוק כך) אלא שמבקשה לכאורה פשוטה זו יצא (אחרי מס' הוספות פשוטות למדי) פרוייקט שכרגע מריצים את החלק השני שלו (הCMD בהפעלת BATCH) בפרוייקטים כבדים המצריכים הפעלה אוטומטית מס' פעמים בחודש בעיבודי דו"חות גדולים. והכל – בהתאמה מינימלית.

(אגב, את החלק של העברה לאקסל זו ניתן למצוא בדף שלי בGITHUB – מי שמעוניין
https://github.com/igalye/Export2ExlEngine)

2.      דוגמה פשוטה יותר  מתחום אחר. לקוחה פרטית ביקשה ליצור גליון EXCEL העושה חישובים שונים (משהו בחשבונאות – סלחו לי – אינני חזק בזה – עושה מה שאומרים לי בלי להבין הרבה 😊 ). אחת התאים כלל חישוב מותנה – אם א' אז... אחרת... טוב, פונקציה IIF מתאימה בול בנושא. ואז – התבוננתי בסוג הנתונים העומדים לרשותי. אינני זוכר בדיוק, אבל זה לא היה סוג דיכוטומי כמו גבר/אשה, אלא משהו בסגנון של משכורת – גדול מN.

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

 IIF (salary>x1, action1, IIF(salary>x2, action2, IIF(salary>x3, action3, action4)))

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

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

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

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

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

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

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

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