Joel on Software

Joel on Software   יואל על תוכנה

 

מאמרים שתורגמו לעברית

גרסה אנגלית

כתבו למחבר

 

דברים שאסור לעשות, חלק א


מאת יואל ספולסקי
תרגום: שלומי פיש
עריכה: חן שפירא
6 באפריל, 2000

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

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

ובכן - כן. הם כן עשו זאת בכוונה. הם עשו את זה בכך שעשו את הטעות האסטרטגית הגדולה ביותר שכל חברת תוכנה  יכולה לעשות:

הם החליטו לכתוב את הקוד מחדש.

נטסקייפ אינה החברה הראשונה שעשתה את הטעות הזאת. בורלאנד עשתה את אותה טעות כאשר היא קנתה את Arago וניסתה להפוך אותו ל-dBase for Windows, פרוייקט מועד לכישלון שלקח זמן רב כל כך, ש-Microsoft Access גנב להם את הבכורה; היא עשתה זאת שוב בכך ששכתבה את Quattro Pro מחדש והפתיעה אנשים בכמה מעט יכולות היו לו. מיקרוסופט כמעט עשתה את אותה טעות, בנסיון לכתוב את Word for Windows מהתחלה בפרוייקט מועד לכישלון בשם Pyramid, אשר נסגר, נזרק וטואטא מתחת לשטיח. למזלה של מיקרוסופט, הם לא הפסיקו לעבוד על בסיס הקוד הישן מה שעשה אותו רק לאסון פיננסי ולא לאסטרטגי.

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

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

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

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

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

מדוע זה בלאגאן?

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

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

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

בחזרה לפונקציה בת שני העמודים. כן, אני יודע, זאת רק פונקציה פשוטה להציג חלון, אבל היא הצמיחה קצת שיער ודברים נוספים ואיש אינו יודע מדוע. בסדר, אז אני אגיד לכם מדוע: אלה הם תיקוני באגים. אחד מהם מתקן את הבאג שקרה לננסי כאשר היא ניסתה להתקין את התוכנה על מחשב שלא היה בו Internet Explorer. עוד אחד מתקן את הבאג שקורה כאשר יש חוסר זכרון. עוד אחד מתקן באג שקורה כאשר הקובץ נמצא על דיסקט והמשתמש שולף את הדיסקט באמצע. הקריאה ל-LoadLibrary מגעילה אבל היא גורמת לקוד לעבוד על גרסאות ישנות של Windows 95.

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

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

אתה זורק את ההובלה שלך בשוק. אתה נותן במתנה שתיים או שלוש שנים למתחרים שלך, ותאמין לי, זה הרבה זמן בשנות תוכנה.

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

אתה מבזבז הון תועפות בכתיבת קוד שקיים כבר.

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

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

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

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

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

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

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



מאמר זה הופיע לראשונה באנגלית בשם Things You Should Never Do  

יואל ספולסקי ייסד את Fog Creek Software, בית תוכנה קטן בניו יורק. במשך שירותו הצבאי (בנח"ל מוצנח) היה בין מייסדי קיבוץ חנתון שבגליל. לאחר לימודים באוניברסיטת ייל, עבד בתור מתכנת ומנהל ב-Viacom, Microsoft, ו-Juno.


אלה דעות של בן אדם אחד ותו לא.
© 1999-2005 Joel Spolsky. כל הזכויות שמורות.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky