האם גם אתם נתקלים במפתחים בעלי "אידיאולוגיה" לגבי כיצד צריך לכתוב תוכנה?

כוונתי לאמונות חזקות שהדרך / הסגנון / העדפות הקידוד שלי הן הדרך הנכונה היחידה לפתח נכון.

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

ואיך כדאי להתמודד עם שוני באידיאולוגיות בין אנשי הצוות?

אשמח לשמוע.

צטט: ziverez 2009-02-21 02:20:35

קוד ואידיאולוגיה

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

 

שמעתי וגם אמרתי. לפעמים קוראים לזה קוד non-IBM: Not Invented by Me.

 

לגבי אידאולוגיה - אני חושב שזה דבר טוב, וגם לי יש דיעה לגבי איך נכון לעשות כל מיני דברים. אבל חשוב להכיר בכך שכל הזמן נקבעים best practices חדשים ושיש דעות אחרות,  וגם הן לגיטימיות ולפעמים יותר טובות. למשל - פעם hungarian notation היה מקובל, והיום בשפות החדשות כמו java ו-c# זה מיותר. או למשל agile - יש לא מעט אנשים שרוצים לעשות agile לפי הספר ויש כאלה שחושבים שאפשר לקחת משם רק חלק מהעקרונות.

 

כל עוד לא מדובר בגישה קיצונית כלשהי, עדיף לדעתי לעבוד עם מישהו שיש לא דעה ואפשר לדבר עליה מאשר מישהו שלא ממש אכפת לו.

 

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

 

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

 

מתי כן לשקול לזרוק הכל ולכתוב מחדש: כאשר צפוי נפח פיתוח גדול וה-design אינו מתאים לחלוטין, כאשר הקוד מלא באגים חמורים שלא נראה שיש להם פיתרון אחר או כאשר יש צורך להתאים את הקוד לטכנולוגיה חדשה שיש לה הצדקה עסקית - למשל מעבר ל-java כדי להיות cross-platform או להפוך אפליקציה מ-c++ לאפליקציית web: במקרים אלה "עטיפת" הקוד הקיים בדרך כלל לא תהיה כלכלית (בחשבון שעות פיתוח).

 

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

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

 

בקיצור, שאלה לא פשוטה.

שווה להקשיב לפודקסט הזה

http://www.reversim.com/

 

 

 

הכי טוב - בסגנון ההונגרי

http://en.wikipedia.org/wiki/Hungarian_notation

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

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

 

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

 

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

צטט: zvikico 2009-02-22 07:48:31

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

מאמר מעולה - תודה.

ספולסקי קולע בול, כתמיד.

מתי לשקול שינוי הדרגתי (לדעתי זה הפיתרון המועדף) - כאשר הקוד כתוב בצורה מזעזעת (לא קריא, צרורות של באגים, design לא מתאים)

מה שנחשב למזעזע בעיני האחד, נראה מסודר וברור בעיני השני.

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

לפעמים יש מקום לדעות שונות, אבל יש מקרים שבהם זה א) ברור לכולם, או ב) אתה/מפתח בכיר עם נסיון יכול לשכנע את האחרים בקלות. נגיד nesting של if עם for ב-15 רמות נשמע לא ממש קריא?

 

קראתי לאחרונה את הספר "clean code" (יש דיון כאן בקהילה) ואני חושב שההגדרות שם של קוד קריא הן טובות (אולי קצת קיצוניות, אבל הכיוון ברור ולדעתי נכון).

צטט: ziverez 2009-02-25 18:39:08

צטט: zvikico 2009-02-22 07:48:31

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

מאמר מעולה - תודה.

ספולסקי קולע בול, כתמיד.

 

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

זעקות "צריך לזרוק את הקוד", מתפתחות לאורך הנתיב הבא:

 

הפרויקט הסתיים, צוות הפיתוח עזב, צוות התחזוקה קיבל לבעלותו את הקוד.

 

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

 

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

 

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

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

 

מה אפשר לעשות?

- כדאי לחשוב על תחזוקת הקוד ולפעול בהתאם - מי יתחזק? אילו כישורים יהיו לו?

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

- לשלב אנשי מפתח מצוות התחזוקה בשלב פיתוח

- להעדיף ככל שאפשר את קריאות ובהירות הקוד על פני מאפיינים אחרים

 

-שרון 

לקח לי כמה שניות להבין מה זה "חליפת בדיקות"...

עברי - דבר עברית ;-)