יום ראשון, 7 בפברואר 2010

מה משמעות השם Refactoring

הגדרה של Refactoring - מאת * וייס שי

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

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

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

דוגמא ל Refactoring

מצב קיים:
בנינו אפליקציית web בשיטת השכבות (Data Access Layer, Business Layer, UI Layer, Common Layer ) באפליקציה זו קיימת פונקציה ב DAL שמקבלת 6 פרמטרים, לפונקצייה זו קורא ה UI דרך ה BL במספר רב של מקומות.

הבעיה:
כאשר מגיעה דרישה שהפונקציה ב DAL תקבל עוד פרמטר שביעי שיהיה אופציונאלי, משמעות של בקשה שכזו היא לעבור על כל הפונקציות בקוד הקוראות לפונקציה הרלוונטית ולבצע את השינוי.

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

תהליך ה Refactoring מורכב מ 3 שלבים פשוטים.
  • זיהוי הנקודות הפוטנציאליות שיכולות להוות בעיה בקוד (Code smell)
  • החלת טכניקת ה Refactoring הרלוונטית לאותה נקודה
  • בדיקה של הקוד והתוצאה של אותו קוד על מנת לוודא שלא שינינו את ההתנהגות החיצונית של הקוד.

הגדרה של Code smell:

Code smells זה הבנה שמשהו לא מריח טוב בקטע קוד ויש בעיה כלשהי בתכנון הארכיטקטוני של הקוד.
"קוד מסריח" יכול להיות משהו פשוט כגון Class גדול שמחולק Classes קטנים, פונקציה גדולה שמחולקת לפונקציות יותר קטנות ויכול להיות דברים יותר מורכבים כגון: איחוד שני classes תחת אותו Class והוצאת Interface או Abstract מתאים או התאמת הקוד לעבודה בתצורה של Design pattern מתאים.


* אודות שי וייס:
וייס שי , מהנדס תוכנה.
בשנים האחרונות מתמחה בהובלת ציוותי פיתוח בסטארטאפים וחברות פיננסיות.


אין תגובות:

הוסף רשומת תגובה