הבנת solid וclean code

[eido]

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

export const deleteAd = async (knex, adId) =>  !!(await knex('ads').where({ id: adId }).del());

או להוספה

export async function insertAd(knex, data) {
  const [id] = await knex('ads').insert(data);
  return id;
}

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

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

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

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

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

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

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

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

[eido]

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

שאלה ב' אינה קשורה ישירות לכותרת או לשאלה א'. מדובר בשאלה כללית על עקרון הכימוס.

ראשית, תודה.
שנית. היא כן, היא נובעת ישירות ממנה. כנראה לא הבינו כוונתי.

אם אנו מבינים שלפי עקרון הsolid והclean code, פונקציה עושה רק דבר אחד והולידציה היא מחוץ לחוק באותה פונקציה, אם כן זה פותח פתח לבעיות, הרי אם יש פונקציה רגישה, ואין עליה שום הגנה, מה ימנע ממני מלהשתמש בה לרעה? ובעצם:

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

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

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

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

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

לענ"ד בלתי אפשרי לצערי... הם לא יודעים מימינם ומשמאלם.

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

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

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

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

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

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

[A0533057932]

פוסט זה נמחק!

[A0533057932]

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

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

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

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

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

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

לענ"ד בלתי אפשרי לצערי... הם לא יודעים מימינם ומשמאלם.

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

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

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

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

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

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

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

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