אנא אפשר JavaScript כדי להשתמש בתכונות הנגישות תכונות נגישות של אתרים על ידי UserWay
top of page
Nissim Elaluf

Beer & OCP Principle.

עודכן: 24 בפבר׳




שלום חברים שבוע טוב

היום נמשיך את חלק 2 בעקרונות הSOLID שחשובים מאוד לבסיס של כל אחד ואחת!

כמו שדיברנו במאמר הראשון

חלק ניכר מאנשי הDATA משתמשים בפייתון ביום יום

אם זה על מנת לבצע טרנספורמציות בתהליכי הETL

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

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

SOLID זה בעצם ראשי תיבות באנגלית של:



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

--------------------------------------------------------------------------


אוקי נתחיל:

במאמר הקודם דיברנו על העקרון הראשון שהוא Single Responsibility Principle | SRP

כל Module שאנחנו כותבים צריך להיות מיועד למטרה ספציפית אחת,

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

היום נמשיך לעקרון הבא Open Closed Principle | OCP

(Open for Extension, Closed for Modification)

שימו לב ישנה סכנה להבין לא כמו שצריך את העיקרון ולפעול בצורה שגויה,

אז בואו ננסה להבין

צריך לכתוב קוד כך שהרכיבים בתוכנה (מחלקות מתודות וכו) לא ישתנו אחרי שסיימנו לכתוב אותם זה בעצם Closed for Modification, אבל מצד שני להוסיף מתודות ופונקציות בשמחה 😊 וזה בעצם Open for Extension.

תכלס אחרי שהבננו את זה – כי זה די פשוט ההנחייה הזו אפשר לחזור לIDE ולעבוד…

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




אוקי

אז שאלה ראשונה היא באמת :

  1. למה לא לשנות קוד שכבר כתבנו? טוב בואו זה די ברור למה אבל בכל זאת אבהיר ככל שהקוד שלנו יותר זקן 👴🏽 כך כמות הבאגים בו תלך ותפחת זה לא שביומו הראשון אנחנו כבר מכירים את כולם אבל מה שאנחנו מכירים ויודעים לפתור אנו פותרים, ומיד אחרי שפתרנו ויצרנו גם כמה חדשים וגילנו עוד, וככל שהקוד לא משתנה אלא רק עובר QA פה ושם אנחנו מבינים אותו מצויין ולאט לאט הסיכוי לבאגים תלך ותפחת. מה יקרה חברים אם נבצע שינוי משמעותי בקוד? מה יקרה אם נשנה משהו שיגרום לשינוי ההתנהגות שלו ? נכון הקוד שלנו יחזור להיות קוד תינוק 👶🏼ובכיין ושוב אנחנו מתחילים להתמודד עם גלים גבוהים של באגים. לא השתכנעתם ? אז סיבה נוספת וחשובה זה הצורך לשמור על קוד כמה שיותר קריא ופשוטוככל שנרחיב אותו הוא יהיה יותר מורכב ומסובך לקריאה רציפה ותקלות זה יהיה כבר רק עניין של זמן.

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



בשלב הראשון אנו כותבים את הקוד הראשוני ולאט לאט מטפלים בכל הבאגים שלו עד שהוא הופך להיות 👴🏽 כאשר אנחנו נדרשים להרחיב את הפונקצינליות אנו מוסיפים את ה”הרחבה” הראשונה והשניה והן כל אחת בזמנה, תהיה קוד טרי ועשיר בבאגים 👶🏼, אבל אם הצלחנו לתכנן את המערכת שלנו כך שפונקציונליות חדשה תגיע כ “הרחבה” –(כמו שהרחבנו על SRP) אז הבאגים יתרכזו באיזור החדש ולא באיזור הישן. וכך גם יהיה מאוד קל להבין כל דבר ולתקן במידת הצורך.

חשוב לדעת דבר נוסף:

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

עכשיו נבין קצת תכלס …

איך אני מיישם את העקרון הנפלא הזה ?

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

מין “Beer matching” שכזה 🍺🍔

בהתחלה אני אכתוב את הבסיס של תנאי שעל פיו הכי קריטי לי ההתאמה שזה ודאי סוג הארוחה (בשרי \ חלבי \ גריל \ מקסיקני\ צמחוני…)



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

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

יתרון נוסף שעכשיו כשאני מכניס תנאי חדש אני יכול להכניס אותו ב MODE בדיקות על 200 התאמות בלבד בשבוע, אחרי חודשיים הרצה אני משנה את הקונפיגורציה שתעבוד על 1000 התאמות ביום (בכדי לבדוק טוב יותר), ורק בסוף השנה, לאחר שתוקנו עיקרי הבאגים – אפעיל אותו על כלל המערכת.

איכות המבנה / העיצוב של ה Matching System (או כל מודול אחר) תלוי בעיצוב הראשוני, ומידה לא פחותה – ברמת ההחלטות וההתאמות שידרשו עם הזמן.

היום הצגתי את העיקרון מספר 2 של SOLID.

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

מימוש של OCP בקוד שלנו יחסוך סרבול מיותר בקוד ויהפוך אותו להרבה יותר ססטיינבילי ונוח לתחזוקה.

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

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

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

נתראה בעקרון הבא

מקווה שנתתי ערך 🍻

Comments


bottom of page