הבנת solid וclean code

[dovid]

@eido

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

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

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

[eido]

כתב בהבנת solid וclean code:

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

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

function addToDb()
{
valid()
insertAd()
}

פשוט יקראו ישירות לinsertAd?

[dovid]

@eido יש כמה טכניקות להשיג גישה פרטית לפונקציה בJS,
אחת מהם נפוצה זה להכניס את הפונקציה insertAd לתוך הפונקציה addToDb (אגב השמות גרועים, כי לא תזכור לפי השם מה עושה מה),
אבל היום משתמשים במודול, אתה פשוט שם את שניהם במודול אבל לinsertAd אתה לא שם export.
פתרון מודרני יותר ומתאים לאיך שעושים בשפות אחרות זה מחלקה (class), אחד התפקידים של מחלקה הוא "כימוס", הסתרה של אלמנטים שלא רוצים שיהיה להם ממשק ישיר, הם נחשבים "פרטיים", בJS זה מסומן עם סולמית לפני שם האלמנט.

[eido]

@dovid כתב בהבנת solid וclean code:

הפונקציה insertAd לתוך הפונקציה addToDb (אגב השמות גרועים, כי לא תזכור לפי השם מה עושה מה),

מה היית מציע?

[dovid]

@eido אל תחשוב שזה קל לי!
ראשית אני לא מתעכב על זה, כלומר גם אני נותן שמות גרועים,
אבל אני מקפיד להחליף אותם (לפעמים חמש פעמים תוך יומיים בשעת הפיתוח).
היום הcopilot בהחלט עוזר לי פה ושם, אבל זה רק עזרה, לא חוסך את הבעיה/האתגר, שסתם ככה הוא בריא מאוד כי הוא גם גורם להגדרה ולמימוש של SOLID.
שנית, השם מאוד מאוד תלוי בהקשר. אם אתה יוצר מחלקה בשביל השמירה לDB או מודול, אתה יכול לנצל את שם המרחב שלהם, למשל dbDirect.insertAd. בגלל שבSQL הוספה זה insert השם insert מתאים יותר לשכבת הSQL, ואילו add או save מתאים למתודה עילית יותר.

[A0533057932]

@dovid כתב בהבנת solid וclean code:

SaveAndRestoreAndNotify

הייתי מחדד יותר
במקרה שיש לך and בשם הפונקציה עברת על הכלל

[dovid]

@A0533057932
יש פעולות שהם יחידה לכל דבר ועם זאת התיאור שלהם מכיל "גם" (למשל "איתור חריגים וחסרים"),
וגם מקרים רבים של מטרה יחידה שתחתיה יכולים לחסות כמה פעולות מאוד מאוד קשורות ואז לגיטימי שיהיה "גם" בשם שלהם.

[A0533057932]

@dovid אכן
אבל כמו שתארת
זה היוצא מהכלל
ככלל
שאתה רואה כזה מילה בשם פונקציה אתה מבין שיש בעיה

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

[A0533057932]

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

[eido]

אז מה הוחלט?

[dovid]

@A0533057932 אני התייחסתי לעיקרון של פונקציה אחת - מטרה אחת, ובעיקר מתי זה כבר חריגה משמעותית מהכלל.
אני לא עובד בכלל עם העקרונות של clean architecture (שזה ספר ופרדיגמת פיתוח על איך לעשות מערכת, הclean code זה של הספר שלו ברמת הקוד) של הדוד בוב.
זה נכון שהזכרתי את SOLID, בטעות, שכחתי שזה ה"סט" שלו.
הוא מאוד טוב במיתוג ויצירת סלוגנים, ולכן השמות שייכים לו (הרעיון של פונקציה ממוקדת כמובן לא שלו, אולם אין לזה שום שם לפניו...), העקרונות שלו מאומצים ומיושמים במידה רבה בתעשיה, אבל אני בכלל לא "גדלתי על ברכיו". אני לא אוהב בכלל את הקיצוניות שלו, ואני חושב שהכללים שלו הם פאנטיים ומביאים בעיות משלהם.
על הclane architecture שמעתי רק לפני שנתיים בערך, וממש לא התחברתי ועם הזמן גם פיתחתי ביקורת של ממש לעקרונות שלו, מה שכולם אומרים ומסכימים שצריך לקחת אותו במידה ולא עד הקצה.
(מה שכן הכרתי ואימצתי זה הספר code complete שהוא בכלל מביע דעות אלא סך הכל מסכם מה עושה נזק ומה עושה תועלת באופן ודאי מהמציאות, וממנו שאבתי עקרונות קידוד, הרבה מהם היו תמיד בקונצנזוס אלא שצריך לשמוע עליהם פעם כדי לקלוט את הכלל).

[dovid]

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

[dovid]

@eido כתב בהבנת solid וclean code:

אז מה הוחלט?

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

[pcinfogmach]

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

א. שאלה ב' אינה קשורה ישירות לכותרת או לשאלה א'. מדובר בשאלה כללית על עקרון הכימוס. ב-JavaScript מיישמים זאת לרוב באמצעות export (והגבלת גישה דרך מודולים), ואילו בשפות מבוססות מחלקות כגון C# הכימוס מובנה בצורה ישירה וברורה יותר באמצעות הגדרת רמות גישה (public, private וכו').

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

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

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

ובשני מילים: "בהירות מודולרית"

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