Joel on Software

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

 

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

גרסה אנגלית

כתבו למחבר

 

חמישה עולמות


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

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

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

אתה קורא ספר על בניית מודל באמצעות UML, ובשום מקום לא נאמר שאין בו הגיון לכתיבת מנהלי התקן של רכיבי חומרה. אתה קורא מאמר שאומר ש"מערכת הריצה שתופסת 20 מגה-בייט (הדרושה ל-NET.) היא אינה בעייה" והמובן מאליו לא מוזכר: אם אתה מנסה לכתוב קוד ל-ROM בן 32KB על איתורית, זוהי מאוד בעיה!

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

  1. תוכנות שוק
  2. תוכנות לשימוש פנימי
  3. תוכנות משובצות חומרה (Embedded Software)
  4. משחקים
  5. תוכנות כתוב וזרוק 
כאשר קוראים את הספר האחרון על Extreme Programming, או את אחד מהספרים המצוינים של סטיב מקונל, או את "יואל על תוכנה", או את מגאזין Software Development, רואים הרבה טענות על איך לבצע פיתוח תוכנה, אבל בקושי רואים כל אזכור של איזה סוג של פיתוח הם מדברים עליו - דבר מצער, משום שלפעמים אתה צריך לעשות דברים באופן שונה בעולמות שונים.

הבה נעבור על הקטגוריות בקצרה.

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

לתוכנת שוק יש בעיות מיוחדות שנובעות משתי תכונות מיוחדות:

  • מכיוון שיש לה כל כך הרבה משתמשים, שהרבה פעמים יש להם אלטרנטיבות, ממשק המשתמש צריך להיות קל יותר מהממוצע כדי שהתוכנה תצליח.
  • מכיוון שהיא רצה על כל כך הרבה מחשבים, הקוד צריך להיות חסין לשוני בין המחשבים. שבוע שעבר מישהו כתב לי דואר אלקטרוני על באג ב-CityDesk שהופיע רק בגרסה הפולנית של חלונות, בשל הדרך שהיא משתמשת בכפתור ה-Alt הימני כדי להכניס תוים מיוחדים. אנו בדקנו אותה על Windows 95, 95OSR2, 98, 98SE, ME, NT 4.0, Win 2000,  ו-Win XP. אנו בדקנו עם Internet Explorer גרסה 5.01, 5.5 או 6.0 מותקן. בדקנו על חלונות בשפות אנגלית אמריקאית, ספרדית, צרפתית, עברית וסינית. אבל לא הגענו לגרסה הפולנית עדיין.
ישנן שלוש וריאציות עיקריות של תוכנת שוק. תוכנת קוד פתוח מפותחת הרבה פעמים בלי שאף אחד יקבל כסף כדי לפתחה, מה שמשנה מאד את הדינמיקה. למשל, דברים שאינם נחשבים ל"כיף" הרבה פעמים לא נעשים בצוות שכולו מתנדבים, וכפי שמתיו תומס מצביע בבהירות, זה עלול לפגוע בקלות השימוש שלה. יש אפשרות גדולה הרבה יותר שהפיתוח יהיה מפוזר מבחינה גאוגרפית, הדבר מתבטא באיכות שונה לחלוטין של תקשורת בין אנשי הצוות. בעולם הקוד הפתוח נדיר שתהיה שיחה פנים מול פנים מול לוח תוך כדי ציור ריבועים וחצים, כך שהחלטות התכנון שהיו משתפרות משימוש בריבועים וחצים - בדרך-כלל מוכרעים בצורה לא מספקת בפרוייקטים כאלה. כתוצאה מכך, צוותים המפוזרים גאוגרפית זכו להצלחה רבה יותר בשכפול תוכנה קיימת שדרוש לה מעט מאוד או שום תכנון.

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

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

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

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

לתוכנה משובצת חומרה יש התכונה היחודית שהיא מוכנסת לתוך חתיכת חומרה וכמעט לעולם לא מעודכנת. כאן זה עולם אחר לגמרי. דרישות האיכות הרבה יותר גבוהות, משום שאין הזדמנות שנייה. אתה עלול לעבוד עם מעבד שרץ הרבה יותר לאט מהמעבד השולחני הטיפוסי, כך שייתכן שתאלץ להוציא הרבה יותר זמן על אופטימיזציות. קוד מהיר חשוב הרבה יותר מקוד אלגנטי. התקני הקלט והפלט הנתונים עלולים להיות מוגבלים. למערכת ה-GPS במכונית ששכרתי שבוע שעבר היה כזה  I/O  פתטי שיכולת השימוש בה הייתה מאכזבת.Picture of Hertz Neverlost GPS האם אי פעם ניסית להכניס כתובת על אחד מהדברים האלה? הם מציגים מין "מקלדת" על המסך וצריך להשתמש בחיצים כדי לבחור אותיות מחמש מטריצות קטנות של תשע אותיות כל אחת. (עקוב אחר הקישור לאילוסטרציות נוספות של ממשק משתמש זה. למערכת ה-GPS במכונית שלי יש מסך מגע שהופך את השימוש בממשק להרבה יותר טוב. אבל אני סוטה מהנושא המרכזי).

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

הבעייה היותר גדולה בפיתוח של משחקים היא שיש רק גרסה אחת. מרגע שהמשתמשים שלך שיחקו ב-"Duke Nukem 3D" הם לא ישדרגו ל-"Duke Nukem 3.1D" רק כדי לקבל תיקוני באגים ונשקים חדשים. עם כמה יוצאים מן הכלל, מרגע שמישהו שיחק את המשחק עד סופו, זה משעמם לשחק אותו שוב. אז למשחקים יש את אותן דרישות איכות כמו לתוכנה משובצת והכרח פיננסי עצום לדאוג שיצאו בסדר על הפעם הראשונה. למפתחי תוכנות שוק יש את המותרות של ידיעה שאם גרסה 1.0 לא עמדה על ציפיות של אנשים ולא מכרה, אז אולי 2.0 כן תמכור.

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

ישנם, קרוב לודאי, סוגים אחרים של פיתוח תוכנה ששכחתי.

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

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

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

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

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

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

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


מאמר זה הופיע לראשונה באנגלית בשם Five Worlds  

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


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

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky