בתשובה למ. השור, 21/09/02 23:12
 |
|
 |
||
|
||||
 |
אני טוענת כבר כמה זמן, שכמויות הבאגים בתוכנות (גם בתוכנות ''גמורות'' ששוחררו לשוק, ולא רק של קוד סגור) לא היו מתקבלות בשום תחום אחר, והן מעידות יותר מכל על חוסר הבשלות של עולם התוכנה. |  |
 |
 |
|
|
|
||
|
||||
|
זו טענה נפוצה, ואני לא מסכים איתה בכלל. הבעיה איתה היא ההנחה המובלעת שכתיבת תוכנה מקבילה לייצור מוצר פיסי. היא לא. תכנות היא בראש ובראשונה פעילות יצירתית ומחקרית, במובן שהיא דורשת משאבים רוחניים משמעותיים ושהיא לחלוטין לא ניתנת לשחזור על ידי אדם או מכונה (על-פי הגדרה -- תכנות מתחיל כשהאוטומציה נגמרת). הרי אין כל דרך אוטמטית לדעת מה קוד בעצם עושה ולעולם גם לא תהיה -- מה שאומר שחייבים להסתמך על האינטואיציה של המתכנת. אינטואיציה. כתיבת קוד מקבילה למדע, לעריכת דין (כנראה לפחות לחלקים הסקסיים יותר של עריכת דין), למחקר מתמטי, לכתיבת תסריט לסרט שובר קופות או לתכנון פרוטוטיפ של דגם מכונית חדשה. אין מה לבוא בטענות לבאגים בתוכנות אלא במידה ובאופן שאפשר לבוא בטענות למדענים על השקעה לא פרופורציונית של משאבים בכיוונים מחקריים חסרי עתיד, או בתיאוריות שהוכחו כשגויות, או כפי שאפשר לבוא בטענות לבמאי על כך שכל סרט שלו נכשל, או לצוות מתכנני מכונית על כך שמשאבים כה רבים מושקעים בבדיקות חוזרות ונשנות (ותיקונים בעקבותיהם) של הפרוטוטיפים. אני בטוח שחוסר הוודאות בכל אחד מהתחומים האלה לא נופל בצורה משמעותית מבתחום התוכנה. התחום במחשבים שמקביל לייצור הוא לא תכנות אלא ניהול מערכות. אני לא מנסה לטעון שלא צריך לנסות לשפר את התהליך, אלא שההייחסות לתחום התוכנה כ-''תעשייה לא בוגרת'' הוא מטעה מלכתחילה ולא יביא לתוצאות הרצויות. הסיבה שכתבתי את כל זה היא שההתייחסות הזו לתכנות היא בדיוק הגישה שבבסיסה ההסתכלות על תוכנה חופשית כדבר לא טבעי -- הרי תעשייה היא דבר המשוייך בד''כ לחברות גדולות ושמוצריהן שייכים בבירור למישהו. אבל לא הרבה טוענים ברצינות שלתת לחברות מסחריות מונופולים מרחיקי לכת על תוצאות מחקרים מדעיים (על פטנטים יש הרבה יותר הגבלות מאשר על זכויות יוצרים, למשל), או על תוצאות מחקרים מתמטיים, או על השימוש בתקדימים משפטיים היא הדרך המובנת מאליה לקדם את ''התעשייה''. | |
|
|
|
|
|
||
|
||||
|
כל זה טוב ויפה בתיאוריה. בפועל, רוב התוכנה הנכתבת נכתבת ככלי יישומי נטו (תחשוב על המילה "יישום"), שעליה אנחנו סומכים לניהול כספים, מסחר, תקשורת, ועוד עוד. כל עוד אתה מוכר (עם או בלי כסף) תוכנה ככלי יישומי, אתה צריך לספק אמינות של כלי יישומי ולא כלי מחקרי (זה לא אומר שאין מקום לתוכנה "מחקרית" - יש. רק אל תשווק אותה ככלי יישומי). זאת במיוחד בהתחשב בעובדה שחלק ניכר מהבאגים חוזר שוב ושוב שוב- אם עקבת פעם אחרי RISKSאו BugTrack אתה כבר יודע את זה. יכול להיות שצריך להפריד יותר בין תכנות "יישומי" ו"מחקרי", אך אין עדיין סיבה שתוכנות "יישומיות" ישרצו בכל כך הרבה באגים (אני עובדת עם מוזילה על בסיס קבוע, ואם אתה כמוני אתה מודע לכמות העצומה של הבאגים שמפריעים לעבודה שוטפת שעדיין יש שם. ועדיין הרבה מפתחים מעדיפים לעבוד על תכונות חדשות במקום לתקן באגים). אפשר בהחלט לכתוב תוכנה עם פחות באגים- צריך לזה סגנון עבודה שונה ממה שיש בהרבה מקומות (ופותחו טכניקות כאלה ומסגרות עבודה שכן עובדות), וצריך לשם כך להאט את קצב הוצאת הגירסאות של התוכנות (לפני כמה זמן יצא מנדרייק 8? ותשע כבר בשלב ה RC). |
|
|
|
|
|
|
||
|
||||
|
שוב פספסתי בהסבר (פעם שנייה בפתיל, מה יהיה איתי). וודאי שתוכנה היא כלי יישומי וכך צריך להתייחס לתוצאה הסופית. אבל הפיתוח שלה הוא תהליך מחקרי, ואנחנו מדברים על פיתוח תוכנה. יש כאן שני נושאים שונים: הראשון הוא בחירת האיזון בין תכונות ובאגים, והשני הוא צורת העבודה הלא-יעילה (מבחינת באגים) של תכנות בימינו, או למה צריך איזון מלכתחילה ואי אפשר לקבל הכל כל הזמן, כמו במכוניות. לגבי השני כבר כתבתי את דעתי. לגבי הראשון: משאבים וזמן עצומים מושקעים ב-"ייצור תוכנה", מתוכם כ%100-, פלוס מינוס, הולכים לפיתוח. אין כאן הרבה כפילות שאפשר להסתמך עליה. בייצור מכוניות, לעומת זאת, אני בטוח (למרות שלא בדקתי) שלא יותר מ, נגיד, %15 מהמשאבים מושקעים בפיתוח, והשאר בייצור נטו. התוצאה היא שכל גרוש וכל יום שהולכים לפיתוח תוכנה יורדים ישר מהעלות הכוללת, בזמן שכל גרוש וכל יום נוספים שהולכים לפיתוח רכב יורדים מסעיף משני שאף פעם לא היווה את נטל עיקרי על המשאבים (או על הזמן) ממילא. חוץ מזה, אם תחשבי על כך, ההחלטה על תכונות-מול-באגים היא יותר של המשתמשים מאשר של המפתחים. הרי בטח שאפשר להאט את קצב הוצאת הגרסאות. מנדרייק הוא דוגמה מצויינת – הפצה של לינוקס שעשתה לעצמה שם ושוק באמצעות הנכונות שלה לכלול גרסאות חדשות ומבהיקות של תוכנות שבקושי נבדקו מספר חודשים, שלא כמו מתחרותיה השמרניות יותר. אז מי שרוצה שרת יציב לבונקר האטומי שלו, יריץ דביאן, או Red Hat 6.x (שעדיין נתמכת יופי). מי שרוצה להתפרע עם פיצ'רים גרפיים מהממים למחשב הדסקטופ שלו בבית יריץ מנדרייק, או את הענף הלא-יציב של דביאן. אבל אין שום מחסור בתוכנה יציבה וותיקה שעושה את העבודה טוב. דוגמה אחרת שלך: למה את עובדת עם Mozilla, למשל, דפדפן חדש מאוד יחסית שהפיתוח שלו עוד לא הסתיים לחלוטין? למה לא עם Lynx, אחד הדפדפנים הוותיקים והיציבים ביותר, כמו שאני עשיתי תקופת-מה בעבר? נכון, הוא תומך רק בעברית לא-לוגית, אבל זה הרי טוב מספיק לאייל. הוא עדיין נתמך על-ידי המפתחים, יעיל, ויציב לאללה. מה זה יציב, בולדוזר לא יזיז אותו. שום Javascript של פרחח, שום HTML שנראה כאילו נכתב במגרפה, שום חתול על המקלדת לא יפעילו אף באג. אפשר לפוצץ פצצת מימן ממש לידו ועדיין לא לגרום לסמן הטקסט הקטן בפינה לצאת משלוותו הסטואית ולהחמיץ הבהוב. אני בטוח שפורד היו מתים לייצר מיכל דלק עם כזאת יציבות. ובכל זאת, מה לעשות, הפסקתי להשתמש בו לטובת דפדפנים חדשים יותר שיש להם תמיכה טובה יותר בטבלאות ובפריימים. או במלים אחרות, אולי אין בו באגים, אבל גם אין בו מספיק תכונות. וקצב הוצאת הגרסאות שלו לא מספק אותי. |
|
|
|
|
|
|
||
|
||||
|
אכתוב לך תשובה ארוכה יותר בהמשך. בנתיים, על רגל אחת: * בעניין הדפדפן, השילוב שלמעלה הוא אחת הסיבות שאני פעילה בכימרה- דפדפן מבוסס גקו שמראש אין לו הרבה תכונות, אך מנסים ליצור אותן עם מעט באגים (הוא עדיין בשלב די מוקדם, כך שכרגע באגים לא חסר). בוויכוח של תכונות מול באגים, מעניין לקרוא בזווית זו את הטענות של משתמשי מקינטוש שנשארו עדיין עם 9 ולא שידרגו ל- osx: (אישית אני משתמשת ב-osx ונורא נהנית ממנו) |
|
|
|
|
|
|
||
|
||||
|
כל הכבוד. אבל למה כימרה ולא סקיפסטון או גליאון, שהפיתוח שלהם כבר מתקדם יותר ולכן כנראה שהדרך ליציבות תהיה קצרה יותר? (אני סתם סקרן, כן? הידע שלי בדפדפנים גרפיים הוא תיאורטי ברובו – מה יותר פשוט יותר טוב בשבילי). הרעיון שכל אחד יכול להרכיב לו את החלקים ולבנות דפדפן הוא נהדר. אגב, אחרי שראיתי כמה איילים משתמשי / מכירי לינוקס יוצאים מהארון אני תוהה את מי אני כבר מכיר מכנסי לינוקס בארץ. את ערן טרומר פגשתי (מה זה פגשתי, חתמתי על מפתח). גם את ברקת, אם זו אותה ברקת. | |
|
|
|
|
|
||
|
||||
|
כי אני לא על לינוקס, אלא על מקינטוש osx (כן, יש לי גם kde מותקן, אבל לצרכים אחרים). כימרה הוא מאוד מקינטושי באופיו, וכמי שאחד השיקולים שלה בבחירה במק היה הממשק, זהו פלוס גדול מאוד. |
|
|
|
|
|
|
||
|
||||
|
אוי ואבוי אם תכנות יהיה דומה במשהו לתכנון מכוניות. מכוניות יתפוצצו על ימין ועל שמאל בגלל שעשית יותר מדי פניות מאז ההתנעה האחרונה... | |
|
|
|
|
|
||
|
||||
|
לא צריך להסחף. במכוניות ובמערכות קריטיות אחרות (מטוסים, מערכות רפואיות) יש הרבה מאוד קוד (בין בצורת תוכנה ובין בצורת תכנון חומרה). הקוד הזה צריך להיות ברמת אמינות גבוהה ונבחן בהתאם. האמת היא שאני לא יודע מה ההבדל בעלויות בין פיתוח realtime לבין פיתוח "רגיל" שהוא יותר "סובלני" לבאגים. שמעתי שבנאסא עלויות הפיתוח של קוד שהוא קריטי ברמה עליונה הן פחות או יותר כמו בחברות תוכנה המפתחות קוד לא קריטי. הסיבה לכך היא שנאסא מיישמת שיטות תכנון וקידוד מתקדמות (ומן הסתם מעסיקה תוכניתנים מוכשרים במיוחד) על מנת למנוע באגים בשלב מוקדם וליעל את תהליך הקידוד. מכאן שתי מסקנות: האחת שניתן ליעל תהליך של פיתוח תוכנה והשניה שללא יישום טכניקות מתקדמות, מימוש של מערכות קריטיות יקר בהרבה מאשר מערכות לא קריטיות. |
|
|
|
|
|
|
||
|
||||
|
נאסה לא מוכנים לקבל באגים. אין אופציה כזאת. לקוחות רגילים מצד שני, ''מבינים'' שבאגים הם חלק מאפיונו של מוצר, ומוכנים לקבל מוצר פגום. אותם לקוחות גם לא יהיו מוכנים לשלם יותר על מוצר נקי יותר מבאגים, ולפיכך לחברות התוכנה לא משתלם לייצר מוצר נקי לחלוטין. השוק לוחץ למוצר פגום ועכשיו, ולא מוצר נקי עוד ששה חודשים. |
|
|
|
|
|
|
||
|
||||
|
א. נאסא מוכנה לקבל פגמים רק אם הם נובעים מכך שחלק מהמהנדסים עובדים בשיטה המטרית ואחרים בשיטה השניה, איך שלא קוראים לה, של האמריקאים. ב. כמה *עוד* מיקרוסופט יכולה לדרוש עבור המוצרים שלה? כבר עכשיו חבילה בסיסית למדי של מערכת הפעלה + אופיס עולה הרבה מעבר לתקציב סביר של משתמש ביתי... |
|
|
|
|
|
|
||
|
||||
|
זהו בדיוק, שהרכרוכי הזעיר אינו יכול לדרוש יותר, וגם אין לו הצדקה, שכן המחיר שהוא גובה אינו תלוי עלות, אלא תלוי הערכתו את נכונות התשלום של הלקוח. | |
|
|
|
|
|
||
|
||||
|
במלחמת המפרץ, הייתה סוללת פטריוט בסעודיה שכשלה לפגוע בטיל סקאד,וכתוצאה מכך נהרגו חיילים אמריקאים. התברר, שעקב באג, היה צורך לאתחל את המערכת כל 8 שעות, ואילו היא עבדה כ- 100 שעות ברציפות. לפרטים: |
|
|
|
|
|
|
||
|
||||
|
המכונית של החברה שלי קורסת הרבה יותר פעמים מאשר ה-WIN2k בו אני משתמש (מומלץ). זאת למרות שאני מתעלל במערכת ההפעלה שלי הרבה יותר מאשר חברתי מתעללת ברכב שלה. יש מערכות הפעלה מאוד יציבות ואמינות. רוב האנשים פשוט לא משתמשים בהן. |
|
|
|
|
|
|
||
|
||||
|
זה המקום לשאול אם משהו יודע כיצד מתגברים על הבעיה/וירוס/וורם באקספלורר שמתחיל לפתוח חלונות שמובילים לאתרים של קניות, קזינו, סקס ועוד. פנדה לא מצאה שום וירוס, העוגיות וה-קאש נוקו וכו'. עזרה באימייל תתקבל בברכת תודה rbj@haayal.co.il |
|
|
|
|
|
|
||
|
||||
|
מדובר בדרך כלל ב"פרזיטים"- תוכנות קטנות המתלבשות על תוכנות שאתה מתקין, ומותקנות יחד איתן. שג ad aware מסוגל לזהות ולהסיר אותם. להשגה ב: |
|
|
|
|
|
|
||
|
||||
|
לא, זאת אינה טעות נפוצה. גם תרופה היא בראש ובראשונה פעילות יצירתית ומחקרית, ולא היית מוכן לקבל מוצר, מהחברה הפרמצווטית השולית ביותר בעולם, באיכות שאתה מוכן לקבל מוצר מחברת התוכנה המובילה בעולם. הדוגמא שנתת לפיתוח אבטיפוס של מכונית דווקא מתאימה יותר. נכון, יש מי שמשקיע באב טיפוס, ויש מי שמפתח אותו (ולפעמים גם יש מי שזורק אותו לפח), אבל אין מי שמוכר אותו לציבור הרחב. האבטיפוס (של המכונית או התוכנה, היינו הך) הינו מוצר בוסר, הדורש שפורים, שינויים, ונפוי שגיאות ותקלות. כל אלו אמורים להתבצע במעבר מאבטיפוס לגירסת המדף. התאור שנתת יכול להתאים אולי לכתיבת תוכנות Taylor Made, או אפילו יישומים של תוכנות מדף, אבל וודאי שלא לתוכנות מדף. |
|
|
|
|
|
|
||
|
||||
|
קודם כל, לא אמרתי טעות נפוצה אלא טענה נפוצה. חלילה לי לפסול גישות מופשטות בצורה כל-כך נחרצת. ולעניין – תרופה היא דוגמה מצויינת כי קריטי שתהיה אמינה. משאבים עצומים, שנים ואפילו עשורים מושקעים בבדיקות חוזרות ונשנות, ואני כמובן כולל זאת בעלות פיתוח. ועדיין יש פשלות. יש גם תוכנה שקריטי שתעבוד טוב – למשל, במרכזיות טלפון. יש גם תוכנה שלא קריטי שתעבוד טוב – למשל, דפדפן. אז מה הבעיה? למה אנשים רוצים שלחוויה הטכנית של דיונים באייל תהיה האמינות של תרופה מצילת חיים? זו נראית לי גישה לא סבירה אם לא מוכנים לשלם עבורה. לגבי ייצור מכוניות – כל התהליך החל מהמחשבה המעורפלת בראשו של ראש מחלקת העיצוב התעשייתי ועד שהרובוטים עומדים מוכנים על קו הייצור ומחכים ללחיצה על הכפתור הירוק הוא חלק משלב הפיתוח. כולל הבדיקות של הפרוטוטיפ, כמובן, בדיוק כמו בתוכנה. אני לא בטוח שאני מבין למה אתה אומר שפיתוח של תוכנת מדף שונה מפיתוח מכונית. | |
|
|
|
|
|
||
|
||||
|
רק למשפט האחרון שלך: אני לא טוען שפיתוח תוכנת מדף אמור להיות שונה מפיתוח מכונית. להיפך. מה שאני כן אומר זה שבמכוניות אנחנו, כצרכנים, הרבה פחות טולרנטים לכשלים (גם כאלה שאינם מסכני חיים) מאשר בתוכנות מדף. (למרות שגם במכוניות נתגלו באגים שאילצו את היצרנים לאסוף את המוצרים מהלקוחות). |
|
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |