דיון

[ברנדל]

דיון

נניח הפילו לכם פרויקט על הראש, משהו רציני באופן בינוני, החברה צריכה בדחיפות לספק ללקוח ואתם מתבקשים להרים את זה כמה שיותר מהר. הבעיה היא שהחישובים שאתם עושים בראש מראים שרק ה oo design יקח לא מעט זמן יקר שאין לכם. מה גם ש oo design די הכרחי לפי דעתכם כי לפרויקט יש עתיד, אם לא תשמרו על סדר, אחרי זה יהיה קשה. מה תעדיפו: א. בכל זאת לתכנן טוב טוב במחיר של הגשת תוכנה ראשונית באיחור, תוך הסבר לממונים שזה המצב. ב. quick and dirty קודם לשחרר משהו ללקוח אולי עם באגים, אולי לא מתוכנן טוב, ואחרי זה לבנות לעצמכם דברים מחדש, למרות המגבלות שבשיטה (סיכון השם שלכם - יצרתם משהו עם באגים, ויכוח עם הממונים - מה פתאום צריך אחרי שהעברנו ללקוח לכתוב חלקים מהתוכנה מחדש)

 

[צונאמי]

נראה לי ...

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

ולא חסרות עוד סיבות)

 

[ברנדל]

כן , אבל גם יש את ענין הלקוח

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

 

[gilad_no]

לגבי באגים,

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

 

[צונאמי]

מי דיבר על עודף תכנון ?

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

 

[vdsp]

דיון

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

 

[Scipio]

מה שממקסם את התועלת

זה לא פשוט וזה תלוי ביכולת שלך לנהל משא ומתן אבל בסופו של דבר התשובה היא כזו : הלקוח תמיד צודק. אתה עובד בשביל הלקוח אתה צריך לדון עם הלקוח ולהסביר לו את ה TRADE OFFS בין זמן איכות כמות ומחיר ובסופו של דבר להגיע למשהו שממקסם את התועלת. אפשרות אחת למשל היא לשבת עם הלקוח ולציג לו את ההדבר הבא: אתה רוצה להוסיף את התכונה הזו והזו. תוריד את התכונה האחרת. / תוסיף כסף אתה רוצה להוריד את זמן הפיתוח = תוריד אילו תכונות הכי קשה זה לכמת את האיכות אבל גם פה אפשר לקחת שוליים. בכל מקרה אפשר להסביר את אלמנט הסיכון בתת נושאים מסויימים (יש נושאים שקל מאד להעריך את זמן הביצוע - ויש כאלה שקשה). בסופו של יום המטרה ששניכם תיצאו מרוצים. ישנה נטייה לפעמים למתכנתים לעשות OVER DESIGNING ולא להבין מה הם הדברים הבאמת חשובים ללקוח. ישנו גם הבדל איזה סוג לקוח זה- לקוח INHOUSE בו לרוב האיכות וקצב העידכונים יכול להיות מהיר או לקוח חיצוני ופה ישנו הבדל בין לקוח שמזמין מוצר לבין לקוחות שקונים מין המוכן. לא תמיד זה צריך להיות QUICK & DIRTY. מה זה פרוייקט בינוני (בימי עבודה)? מה רמת הסיכון בו? האם הקשיים הם טכנולוגים / ידע? החיים קשים

 

[DadleFish]

XP פותר לך באלגנטיות את הבעיה הזו.

הכוונה היא לא ל-WinXP אלא ל-eXtreme Programming. השיטה המסורתית של OOD לפיה צריך לתכנן הכל מראש, וכל מה שלא יתוכנן ייראה בסוף רע, היא שיטה לא טובה שהוכחה ככזו שאין לה סיכוי להצליח. בסופו של דבר (בעולם האמיתי) תמיד יהיו דברים חדשים שיצוצו על הדרך, ותמיד יהיו FEATURE-ים שיירדו או שיתוספו. מה הפתרון? איטרציות. תקרא קצת על XP באתר הזה. מה שמעניין אותך זה בעיקר CRC Cards, User stories, Refactoring וגם על כל השאר. זו הדרך לבנות תוכנה בלוק אחרי בלוק, בלי לתכנן הכל מראש, ולהגיע לתוכנה איכותית, יציבה, שאפשר כל הזמן להרחיב ולשפר בלי לשבור את ה-DESIGN הקיים (שמתהווה עם הזמן).

 

[ברנדל]

אלדד

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

 

[DadleFish]

המממממ...

הרבה פעמים, כמו שסקיפיו ציין פה בין השאר, תוכניתנים - או לפחות האנשים שעושים DESIGN - נוטים להניח הנחות (בלתי מבוססות) לגבי העתיד. במשך העשור הקודם חונכנו שצריך לחשוב על הכל מראש, וכל דבר שלא נחשוב עליו עכשיו, יתנקם בנו בהמשך. זה יכול היה להיות נכון, אילולא היו בשיטה הזו שתי בעיות אקוטיות: 1. אי אפשר לחשוב על הכל מראש. תמיד תהיינה הפתעות, ותמיד נפספס דברים; 2. כשחושבים מראש על צרכים עתידיים, הרבה מהעבודה היא עבודה מיותרת שאף אחד לא יצטרך לעולם. ראיתי כמה מודולים מתוכננים בגנריות מרשימה מאוד, ובפועל הם משמשים אך ורק ליישום אחד. מה הטעם בכל הגנריות? זו רק דוגמה אחת. XP כשמה כן היא. Extreme. זה אומר שהשיטה הטובה ביותר לעבוד היא לעבוד באיטרציות קצרות שנותנות לך להחזיק ביד כל הזמן משהו שעובד, עם כמות FEATURE-ים מסוימת, ושיטות מסודרות לביצוע REDESIGN איפה שצריך כדי להוסיף FEATURE-ים. במקום לעבוד בשיטה המסורתית, כלומר להינעל על DESIGN אחד ויחיד, גלובלי, ולהוסיף עליו PATCH-ים - ב-XP ה-DESIGN הוא דבר נושם שמתקדם יחד עם הפרויקט כל הזמן. REFACTORING היא השיטה שלוקחת OOD אחד ומשנה ומשפרת אותו כדי לאפשר FEATURE-ים נוספים.

 

[ברנדל]

כלומר כל פעם לשנות

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

 

[DadleFish]

תלוי איזה סוג של DESIGN

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

 

[gmorphus]

עכשיו אתה מדבר

קראתי את ההודעה הקודמת שלך ודי הופתעתי. DESIGN הוא דבר מאוד חשוב (!) ואם אתה תשב לכתוב מערכת רצינית (אני לא מדבר איתך על תוכנית שמכפילה מטריצות) בלי לתכנן מראש אתה תהיה בבעיה רצינית. ואני אומר את זה מנסיון. למרות זאת (וOOD זאת שיטה טובה) לא חייבים לדעתי לתכנן הכל מההתחלה עד הפרט האחרון, וגם אם כן עושים את זה, עם התכנון הוא טוב ניתן בקלות לשפר, להרחיב, להוסיף, לגרוע, לשנות. זה חלק מהרעיון של DESIGN טוב - DESIGN שחלק מהדברים שהיו למתכנן בראש בשלב התכנון הוא יכולת הרחבה והתמודדות עם עומסים גדולים, הוספת features, שינוי מודולים קיימים וכל זאת במאמץ כמה שיותר קטן. כמובן שהתכנון צריך להיות משהו נושם, כי אי אפשר לדעת מה יהיה בעוד כמה שנים, בדיוק כמו שלא ידענו מה יהיה היום לפני עשר שנים ("משבר התוכנה"). ואסור להיות מקובעים על הDESIGN הראשוני ולהיות פתוחים לשינויים. אני לא בטוח בדיוק למה התכוונת בPATCH-ים אבל אם זה במובן הידוע של המילה אז לדעתי זה רע! מאוד. למה? כי אם אתה מוסיף איזשהו patch שלא משתלב טוב בתכנון שלך, הוא יהיה תקוע איפשהו במערכת ומאוד יפריע להוסיף ולהרחיב את המערכת בעתיד. בנוסף, בקלות אתה עלול לשכוח לעדכן את הpatch הזה כשתרחיב את המערכת בעתיד. נכון, כמדובר באחד או שניים כאלה זה לא נורא, אבל כשיש הרבה הרבה יותר זה הופך לבעיה גדולה.

 

[DadleFish]

אל תדאג,לא קברתי את ה-DESIGN.

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

 

[gmorphus]

אני אכן יודע

ותיארתי לעצמי שלא קברת את הDESIGN רק רציתי להיות בטוח שאנחנון משדרים על אותו גל

 

[חובבן]

יש לי שתי בעיות עיקריות עם XP

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

 

[DadleFish]

זו הסתכלות שטחית על השיטה.

יש הרבה אנשים שאומרים משהו כמו "כן, פיתוח בזוגות! היי, זה נשמע כמו רעיון נחמד, ובטח הקוד ייצא יותר טוב, ויותר מהר, אבל אין לנו מספיק אנשים בשביל זה". (הפסקה האחרונה מתייחסת לכל מה שאמרת - גם UNIT TESTING, גם PAIR PROGRAMMING, וכו') זו טעות בסיסית בתפיסה שנובעת מקבעון על השיטות המסורתיות. אתה חושב שבהכרח, אם תעבוד יותר על UNIT TEST, אז ברור שהזמן של הפיתוח יוכפל. אם תשים שני תוכניתנים על הפרויקט - ברור שהזמן יוכפל. לא נכון. פשוט לא נכון. אני ממליץ לך לקרוא יותר על XP, ואז תבין בדיוק למה לא. אין לי סבלנות לכתוב פה הכל וממילא הספרים מסבירים הרבה יותר טוב ממני. אני אתן רק דוגמה קטנה אחת. UNIT TESTING, או קוד שבודק את עצמו, מכיל בדיקות שרצות תמיד, איך שהמערכת עולה (לפחות בזמן הפיתוח-DEBUG). אלו בדיקות שדואגות לעבור על כל הקוד, לבדוק EXTREMES וכן הלאה. אלו בדיקות שכותבים פעם אחת, לפני כתיבת הקוד האמיתי, ויש להן שני יתרונות אדירים. הראשון - הן מגבשות את ה-INTERFACE ההכרחי במודול; ושנית - הן גורמות לבאגים לצוף מייד. זה הקטע היפה. אתה עושה תיקון - ומייד מגלה איפה פגעת, אם פגעת. קרבת הזמן בין גילוי הבאג לבין ביצוע השינוי גורמת לך לתקן את הבאג פי 10 יותר מהר. דווקא בפרויקטים שיש בהם מגבלות זמן קשה XP הוא הדרך היחידה האפשרית. יש עוד שתי דרכים, ושתיהן קיצוניות מדי: "לזרום" ולכתוב קוד כמו משוגעים, שאני חושב שזה משהו שהפסקתי לעשות בגיל 18, ומהצד השני לעשות DESIGN מסודר לכל פרט ופרט - OVERKILL שיגרום לביטול הפרויקט. XP, מצד שני, תיתן לך מהר מאוד משהו ביד, שאפשר להרחיב לאט לאט (או מהר מהר

).