Joel on Software

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

 

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

גרסה אנגלית

כתבו למחבר

 

צחצח והברק


מאת יואל ספולסקי
תרגום: שלומי פיש
עריכה: רן קצמן ואורנה אגמון
23/1/2002

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

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

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

אחרי שזה קרה מספר פעמים, הייתה לי הארה – אילו יכולתי למכור את אותה תוכנה, נאמר, לשלושה אנשים, הייתי יכול לדרוש 2000 דולר ולקבל יותר כסף. או לשלושים איש עבור 200 דולר. תוכנה היא די מגניבה במובן הזה. וכך, בסוף שנת 2000, מייקל ישב והמיר את הקוד שיעבוד על Access או על SQL Server, שם את כל הקוד הספציפי לאתר בתוך קובץ רישא (header file), והתחלנו למכור את פ'וג באגז. לא ממש ציפיתי שייצא מזה הרבה.

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

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

אז הכנו גם גרסה 2.0. זה היה ניסיון להוסיף חלק מהתכונות הנחוצות ביותר. כאשר דייויד עבד על גרסה 2.0 ממש לא חשבנו שזה היה שווה כל-כך הרבה מאמץ, אז הוא נטה לעשות דברים במה שעשוי להיקרא שיטה "תכליתית" במקום, נאמר, "שיטה אלגנטית". הרשינו למספר, אהם, בעיות תכנון בקוד המקורי להעלות שם עובש. היו שני עותקים שלמים של קוד כמעט זהה בשביל להציג את דף עריכת-הבאגים הראשי. הצהרות SQL היו מפוזרות בתוך ה-HTML, לימין ולשמאל, קדימה ואחורה, צפונה ודרומה. קוד ה-HTML שלנו היה חורק ותוכנן לדפדפנים העתיקים ההם שהיו כל-כך רוויי-באגים שהיו יכולים ליפול בטעינה פשוטה של about:blank.

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

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

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

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

 

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


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


  • שיניתי את כל ה-HTML ל-XHTML. למשל: <BR> נעשה <br />, כל התכונות (attributes) הושמו במרכאות, ווידאתי שכל התגים המקוננים (nested tags) תואמים, וכל הדפים עברו בדיקת נכונות.
  • הסרתי את כל הוראות העריכה (תגי <FONT> וכו') ושמתי הכל בגיליון סגנון של CSS.
  • הסרתי את כל הצהרות ה-SQL מקוד התצוגה ואכן מכל הלוגיקה של התכנית (מה שטיפוסי המכירות אוהבים לקרוא "כללי העסקים"). דבר זה עבר למחלקות שלא ממש עברו תכנון מסודר – אני פשוט הוספתי שגרות (methods) בעצלות כשגיליתי צורך בהן. (במקום כלשהו, מישהו עם ערמה גדולה של קלפי 4x6 מחדד את העיפרון שלו כדי להוציא לי את העיניים. למה אתה מתכוון בכך שלא תכננת את המחלקות שלך?)
  • מצאתי קטעי קוד כפולים ויצרתי מחלקות, פונקציות או שגרות-מחלקה (methods) כדי למנוע את הכפילות. שברתי שגרות גדולות למספר שגרות קטנות יותר.
  • הסרתי את כל הטקסט שנותר בשפה האנגלית מהקוד הראשי ובודדתי אותו בקובץ רישא יחיד כדי לאפשר תמיכה קלה יותר בשפות מרובות.
  • ארגנתי מחדש את אתר ה-ASP כך שתהיה נקודת כניסה יחידה במקום הרבה קבצים שונים. זה עושה את זה מאוד קל לעשות דברים שהיו בעבר קשים – למשל, אנו יכולים עכשיו להציג הודעות שגיאה לגבי הנתונים שהמשתמש הכניס באותו טופס שבו הקלט הלא -חוקי הוכנס. דבר כזה צריך להיות מאוד קל אם ממקמים דברים נכון, אבל אני לא מיקמתי דברים נכון כאשר למדתי תכנות ב-ASP אז.


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

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

הנה הדברים הטובים בקשר לפעילות צחצוח הקוד שלי:


  • היא לקחה הרבה פחות זמן מאשר שכתוב מלא. בוא נניח (בהתחשב בכמה זמן זה לקח לנו להגיע עד לכאן עם פוג-באגז) ששכתוב מלא היה לוקח שנה. ובכן, זה אומר שחסכתי 49 שבועות של עבודה. 49 שבועות אלה מייצגים ידע בתכנון של הקוד שבו לא נגעתי. אף פעם לא הייתי צריך לחשוב, "או, אני צריך שורה חדשה כאן". רק הייתי צריך לשנות <BR> ל- <br /> ללא מחשבה ולעבור הלאה. לא הייתי צריך לברר איך שיטת ריבוי-החלקים עובדת בשביל העלאת קבצים. זה פשוט עובד. רק לנקות את זה קצת.
  • לא יצרתי באגים חדשים בקוד. מספר באגים קטנים, בוודאי, הצליחו לחדור פנימה. אבל לא עשיתי את סוגי הדברים שגורמים לבאגים.
  • הייתי יכול לעצור ולשווק את המערכת בכל זמן אם היה בכך צורך.
  • לוח-הזמנים היה צפוי לחלוטין. אחרי שבוע של עבודה כזאת, אפשר לחשב בדיוק כמה שורות של קוד מנקים בשעה, ולקבל הערכה מאוד טובה לייתר הפרויקט. נסו את זה, אנשי הטיית-הנהרות של מוזילה.
  • הקוד עכשיו הרבה יותר מתאים להוספת תכונות חדשות. אנו בוודאי נרוויח את שלושת השבועות בחזרה עם התכונה העיקרית החדשה הראשונה שנממש.

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



מאמר זה הופיע לראשונה באנגלית בשם Rub a dub dub  

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


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

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky