בתשובה להאייל האלמוני, 13/04/08 15:07
 |
|
 |
||
|
||||
 |
באמת? ז"א ברור שלא בצורה קיצונית כל כך (בדיוק כמו שחברות IT לא מתנהגות באמת כך), אבל האם בהגזמה זה נכון גם עבור חברות מהסוג הראשון? האם זה נפוץ או לא בלתי שכיח בעליל, למשל, שחברת תוכנה גדולה כמו IBM זורקת פרויקט לפח, לאחר שהושקעו בו שעות עבודה רבות ולמרות שחוות הדעת של רבים מהמהנדסים הזהירה מראש שזה הכיוון אליו הולך הפרויקט? |  |
 |
 |
|
|
|
||
|
||||
|
אני מניח שנאסא אמורה להיות דוגמה קלאסית לרמה טכנולוגית משובחת אולם התחקירים לאחר התפוצצויות המעבורות שלהן מעוררי צמרמורת. מה יגידו אזובי הקיר? |
|
|
|
|
|
|
||
|
||||
|
היה לי מרצה להנדסת תוכנה (אאז"נ הוא עבד ב-IBM) שטען שרוב מוחלט של שורות הקוד שנכתבות בשוק התוכנה, נכתבות על מנת להזרק לפח בסופו של דבר. גם בפרויקטים שנחשבים למוצלחים בסופו של דבר. האם יש שמץ של אמת בטענה? | |
|
|
|
|
|
||
|
||||
|
מנסיוני הצנוע, יותר ממחצית זמני הושקע בפרויקטים שפני לקוח לא שזפו אותם. | |
|
|
|
|
|
||
|
||||
|
ומה אופי החברה בה אתה עובד? מה התחום? | |
|
|
|
|
|
||
|
||||
|
תוכנה. דיברנו על שורות קוד, לא? | |
|
|
|
|
|
||
|
||||
|
זה בדיוק נושא הפתיל והקונספציה המוטעת שהוא מעלה: תוכנה זו מילה כללית מידי והיא כוללת סוגי עבודה שונים ומגוונים. איזה תחום בתוכנה? | |
|
|
|
|
|
||
|
||||
|
השורות שנזרקות לפח זה לא תמיד דבר רע. כאשר אני משפר תוכנית בסוף התהליך התוכנית המשופרת היא בדרך כלל קצרה מהמקורית. |
|
|
|
|
|
|
||
|
||||
|
בנאי טוב לא מותיר את הפיגומים מסביב לבנין. (או משהו בסגנון..) |
|
|
|
|
|
|
||
|
||||
|
הלוואי והיה מדובר בפיגומים. על פי רוב במצבים כאלה אני מסתכל על הקוד המקורי ושואל את עצמי מה לעזאזל חשבתי כשכתבתי אותו. |
|
|
|
|
|
|
||
|
||||
|
"Plan to throw one away; you will anyhow."
|
|
|
|
|
|
|
||
|
||||
|
"If you plan to throw one away, you'll throw two."
|
|
|
|
|
|
|
||
|
||||
|
לתכנת קצר ונקי מלחתחילה, לאחר תכנון ארוך ומושקע בו לא כותבים אפילו שורת קוד אחת, זו הדרך אותה אני מעדיף. הבעיה היא למכור את הדרך הזו למנהלי פרויקטים שמרגישים נוח רק אם יש התקדמות ''אמיתית'' (לשיטתם). | |
|
|
|
|
|
||
|
||||
|
אני מעדיף לכתוב בחצי שעה את כל הפרוייקט בשלוש שורות קוד וללא שום באג. תכנון ארוך ומושקע לא באמת פותר את כל הבעיות. גם הגישה ההפוכה של extreme programming לא פותרת את הבעיות. בואו נכיר בזה שכנראה מדובר בבעיה קשה וששיטות הנדסת התוכנה למניהן אומנם מועילות אך בטח לא מושלמות. |
|
|
|
|
|
|
||
|
||||
|
אה, בטח. ניזכרתי מי היה זה שאמר שהעביה כנראה קשה ושנצטרך ללמוד לחיות עם זה. |
|
|
|
|
|
|
||
|
||||
|
למרות זאת, הוא גם אמר שכן יש הבדל מהותי בין מתכנתים טובים לבין מתכנתים ממש טובים. אי אפשר לפרמל, להגדיר שיטה חד משמעית או לסכם את אומנות הנדסת התוכנה למספר כללי אצבע, אבל האומנות קיימת בכל זאת. המתכנתים הלא ממש טובים צריכים ללמוד לחיות עם זה. | |
|
|
|
|
|
||
|
||||
|
נכון. אני מבכה את זה שגם המתכנתים הממש טובים יוצרים באגים לעיתים. |
|
|
|
|
|
|
||
|
||||
|
ממש לא נחון! | |
|
|
|
|
|
||
|
||||
|
עזוב אותך מתכנון. מתכנת אמיתי עובד רק בניסוי וטעיה. | |
|
|
|
|
|
||
|
||||
|
ואם הוא ממש רציני, גם אינו מתעסק עם ניסוי. | |
|
|
|
|
|
||
|
||||
|
ואם הוא עוד יותר רציני, הוא גם אינו מתעסק עם טעיה אלא מתרכז בהטעיה. |
|
|
|
|
|
|
||
|
||||
|
לא בלתי שכיח זה כמו, נניח, שכיח? | |
|
|
|
|
|
||
|
||||
|
כן. לא בלתי שכיח בעליל זה כמו, נניח, מתרחש מידי פעם גם אם לא נפוץ. | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |