DCSIMG
Don't Get Lazy - Liran Chen's Blog

Liran Chen's Blog

.Net Internals, Debugging, Multithreading - and More!

Don't Get Lazy

כשמתכנתים מתחיל להתעצל, דברים רעים מתחילים לקרות. בהתחלה כותבים איזה Anoynmous Method, אחר כך מזדרזים ומשרבטים Extension Method ... ובעיקר, הופכים את הקוד לפחות קריא ונוח לתחזוקה.
אחד ה-"Horror'ים" שכדאי להמנע ממנו, הוא השימוש בפונקציות "הנוחיות" השונות שמספקת לנו מחלקה Array. אני מתכוון לכל הפונקציות שמקבלות מצביע לפונקצית עזר כלשהו, שמופעלת על כל איברי המערך. למשל Find, ForEach, TrueForAll... וכדומה.
במבט מהיר, הפונקציות האלה יכולות להראות נוחות ושימושיות. אחרי הכל, חסכנו כתיבה של לולאה! או בהערכה חופשית: חסכנו לעצמנו גג עוד 4 שורות קוד. ומה קיבלנו בתמורה? קוד שבזמן דיבאג יהיה הרבה פחות נוח לדבג. בואו נאמר שיש איזשהיא בעיה ב-Predicate שהעברנו, או שאנחנו סתם מדבגים דרך איזשהו קטע קוד, ואנחנו רוצים לראות איך Find מחפש בתוך המערך שלנו. אבל מה, בגלל שחסכנו 4 שורות קוד, אין לנו בלוק קוד נחמד ונוח של לולאה בה אנחנו יכולים בקלות ובבהירות לעבור איבר-איבר במערך ולראות באמת מה קורה עם כל אחד מהם. במקום זה, אנחנו צריכים להציב breakpoint חדש בתוך פונקציות העזר שהגדרנו, כדי שנוכל לתפוס כל הפעלה נפרדת שלה על כל איבר במערך (ושמן הסתם לא נדע בדיוק באיזו איטרציה מדובר, אבל זה כבר.. מינורי).
בשורה התחתונה, כן. חסכנו 4 שורות קוד ... אבל באיזה מחיר? במחיר של הוספת קושי חסר טעם על עבודת הדיבאג. כך שבסופו של דבר, אנחנו רק מפסידים. במקום זה, עדיף להפסיק להתעצל לרגע, וכן, להוסיף את הכמה שורות האלה עבור הלולאה שלנו. הקוד יהיה אותו קוד בסופו של דבר, אז למה שלא נקל מעט על עצמנו על הדרך? :)

תוכן התגובה

Ariel Ben Horesh כתב/ה:

לא מסכים.

דבר ראשון הקשר בין הדוגמא לשימוש ב-ExtensionMethods ו-  

Anonymous delegats הוא מקרי בהחלט, ניתן להבין ששימוש בטכניקות הנ"ל משמהו קוד בלתי ניתן לדיבוג וקושי בהבנה הקוד מה שאינו נכון כלל וכלל.

לדעתי האישית, לגבי החלק השני של הפוסט שמדבר על perdicates בפונקציית Find למשל אז

א. זה לא כזה מסובך לדבג.

ב. קןד קלרטיבי יכול לעבור אופטימיזציות בצורה הרבה יותר קלה  לקומפיילר(PLINQ וכו').

לסיכומו של עניין כמו כל דבר, יש צורך להתרגל לצורת עבודה. ממליץ לך להתסכל על AXUM, ו-F#, ללמוד שפות שונות עוזר לא להתקבע לסגנונות ישנים.

# June 9, 2009 12:48 AM

spiritus asper כתב/ה:

הקשר ל-Extension Methods נעשה בהקשר קריאות הקוד. בסופו של דבר שימוש ב extension methods לא פותר לנו בעיות שהיו "בלתי פתירות" עד היום. אבל הצורה בה היא עובדת יכולה רק לבלבל מפתחים עקב "ערבוב" ה-API הלא מסודר הזה. התרומה שאנחנו מקבלים כאן היא מאוד נמוכה, אנחנו למעשה לא מרוויחים שום דבר, והיינו יכולים לפתור הכל עם איזו מחלקת Utility סטאטית. יצא לי לשמוע טיעונים שתומכים בהן, אבל למען האמת.. עדיין לא שמעתי משהו שבאמת גרם לי להשתכנע לגבי טיבם.

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

# June 9, 2009 7:05 AM
שלח תגובה

(שדה חובה)  

(שדה חובה)  

(אופציונלי)

(שדה חובה) 

Please add 1 and 2 and type the answer here:


Enter the numbers above: