למה אתה עדיין משתמש בחץ וקשת ? תעבור לבליסטראות.

10 בפברואר 2007

תגובה אחת

השבוע אצל אחד מהלקוחות שלי שוב נתקלתי ב Visual Studio 6. ושוב פעם עלה לי הסעיף. מילא, אם הפרויקט היה פרויקט של VB, שאני יכול איך שהוא לקבל את הקושי, של הטמעת נושא ה OO אצל מי שמעולם לא נחשף אליו (נושא לדיון נפרד). אבל הפרויקט הוא פרויקט של ++ C, עם הרבה שורות קוד, והלקוח עדיין משתמש ב VS6.

ישנם כמה סיבות לכך שפרויקטים של ++ C נשארים תקועים ב VS6 וכולם לא נכונות.

1. ישנם כאלה שסבורים שמעבר מ VS6 משמעותו שהקוד שלהם עובר מ UnManaged ל Managed, דהינו הקוד ירוץ תחת דוט נט CLR, וזה כמובן דבר רע, זה ישפיע על הביצועים, זה טכולוגיה חדשה, יהיו בגים חדשים ובקיצור זה המון צרות. למיקרוסופט יש הרבה תרומה לסברה הזו, שכן באותה תקופה שיצא VS דוט נט, הם צרפו את הסיומת דוט נט לכמעט כל דבר שזז, היה SQL דוט נט ו Windows Server דוט נט ו Office דוט נט. אנשי השיווק ראו בזה הזדמנות מיתוג ושפכו באותה הזדמנות את תינוק ה CLR – י יחד עם מי השיווק.

זו כמובן שטות מוחלטת, כשאתה ממיר פרויקט ישן של ++ C מ VS6 ל VS2005 הוא לא ממיר לך אותו לקוד מנוהל אלא לקוד Native בדיוק כמו ב VS6 (רק לקוד יותר טוב אבל על זה בהמשך).

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

2. הטיעון הבא שאני שומע הוא ש"ניסינו לעבור וקיבלנו כל כך הרבה Errors כך שירדנו מזה מייד".

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

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

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

אני מעורב בהרבה פרויקטי המרה של קוד ++ C מ VS6 ל VS2005. אני יכול לתת רשימה מפה ועד להודעה חדשה של טעויות שהקומפילר העדכני מגלה והישן לא.

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

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

3. הטיעון הבא שאני שומע הוא ש"ניסינו לעבור וקיבלנו כל כך הרבה Warnings כך שירדנו מזה מייד".

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

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

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

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

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

4. זה כלי חדש, נחכה שיגלו את כל ה Bug – ים שלו ואז נעבור.

לתשומת לב VS2005 יצא ב 2005 אנחנו ב 2007.

ואז כמובן באים אלי ואומרים לי (כאילו שכל מה שהסברתי עד כאן לא מספיק), אז למה כדאי לי לעבור ל VS2005.

אז להלן כמה סיבות נוספת:

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

במאי 2005 ביקרו בארץ חלק מקבוצת הפיתוח של ++ C במיקרוסופט והעבירו יום שלם על ++ C תחת הכותרת "Visual C++ Accelerator Tour". פעם היתה גישה נוחה לכל הדברים הללו תחת "ארועים קודמים" באתר מיקרוסופט ישראל, אבל לאחר שהם התקדמו למימשק העולמי, אני יכול למצוא יותר בקלות לאיזה Webcast נרשמתי בשנת 2004 מאשר איפה לעזזל המצגות וההקלטות של ארועים שהיו בארץ. בכל אופן, מצאתי את האתר של הארוע ומצורף קישור למי שרוצה חומר נוסף על "למה ++ C של 2005 טוב יותר מזה של VS6".

http://msdn2.microsoft.com/en-us/visualc/aa336400.aspx

ולהלן ציטטה מהמקורות:

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

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

תגובה אחת

  1. mayafit12 בפברואר 2007 ב 0:07

    אני מפתח בעזרת visual studio 2005 מזה שנה וחצי. מפתח מערכת המורכבת מחלקים ב c# , חלקים ב c++/CLI וחלקים ב native c++ . איתי עובדים אנשים נוספים המפתחים ב c++.רב הטענות שהעלית הן נכונות,אך הרשה לי להתייחס להערה מספר 4 : אמנם אנחנו ב 2007 אבל פעמים רבות אני מרגיש שאנחנו ב 2004.יש ימים שבהם אני מדמיין איך אני אישית מולק את ראשם של מפתחי הכלי. אם זה קריסות משונות (פתאום הכלי נעלם מהמסכים !!!) אם זה שגיאות מעצבנות (fatal error in compiler….) אם זה נפילות של הכלי או עצירה של צביעת הקוד, או קפיאה של מנגנון ההשלמה וכו' וכו' וכו'. וכל אלא לאחר התקנת sp1 !!!!!
    שלא לדבר על מהירות. יש לי מכונה עם 2 גיגה זיכרון וכל פעם שאני פותח את הפרוייקט אני יכול להכין קפה לגדוד שלם עד שהוא מסיים לעלות. ואוי ואבוי אם במקרה שכחתי לסגור כמה קבצי קוד בפעם הקודמת שסגרתי את האפליקציה….
    לפני כשבועיים הצלחתי לשכנע מספר אנשים אצלי בצוות לעבור לכלי. אחרי שהם התקינו אותו (חצי יום ) ואת ה sp1 שלו (עוד שעתיים) הם פתחו בו פרוייקט ( עוד חמש דקות) וקימפלו אותו (10000000 טעויות).אחרי זה הם כבר התחילו לבכות.
    אפשר בהחלט להגיד הרבה דברים טובים על הכלי(visual studio 2005) , אבל הייתי שוקל פעמיים ושלוש אם לעבור לעבוד איתובפרוייקטים מ VS6 .
    ולסיום טיפ : אפשר להגדיר ב VS6 קומפיילר אחר (למשל את זה של ה VS2005 ) וכך להנות הן מהאמינות היחסית של VS6 (בכל זאת , יש שם כבר 3-4 sp's) והן מהקומפיילר החזק.

    אלון מה-יפית

    הגב