הבנת solid וclean code

[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 וכו').

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

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

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

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

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