הבנת solid וclean code
-
@A0533057932
יש פעולות שהם יחידה לכל דבר ועם זאת התיאור שלהם מכיל "גם" (למשל "איתור חריגים וחסרים"),
וגם מקרים רבים של מטרה יחידה שתחתיה יכולים לחסות כמה פעולות מאוד מאוד קשורות ואז לגיטימי שיהיה "גם" בשם שלהם.- מנטור אישי בתכנות והמסתעף – להתקדם לשלב הבא!
- בכל נושא אפשר ליצור קשר dovid@tchumim.com
-
@A0533057932
יש פעולות שהם יחידה לכל דבר ועם זאת התיאור שלהם מכיל "גם" (למשל "איתור חריגים וחסרים"),
וגם מקרים רבים של מטרה יחידה שתחתיה יכולים לחסות כמה פעולות מאוד מאוד קשורות ואז לגיטימי שיהיה "גם" בשם שלהם.@dovid אכן
אבל כמו שתארת
זה היוצא מהכלל
ככלל
שאתה רואה כזה מילה בשם פונקציה אתה מבין שיש בעיהכחריג לזה זה פונקציה קונטרולר אבל אז אני בדרך כלל מוצא שם יותר מתאים מאשר להשתמש בand
-
עד כמה שהבנתי (לא קובע עובדה, לא מצהיר, לא יודע, רק מה שואל ממה שהבנתי), חלק ממה שזה אומר זה שלפונקציה תהיה אך ורק רק מטרה אחת ורק אותה היא תיישם, ולכן ברגע שאני שם סינון קלט או בדיקות תקינות בפונקציה שמטרתה הוספת מידע למסד נתונים אני עובר על הכלל הזה.
אכן לא הבנת.
פונקציה יכולה לעשות מליון פעולות וזה מעולה.
הכלל הוא ש"פונקציה עושה דבר אחד" הוא שלפונקציה חייבת להיות מטרה אחת, ולא שניים.
זה לא עניין של כמה פעולות קורות, אלא האם יש לכלל הפעולות האלו שם אחד, האם הכל חוסה תחת מטריה של מטרה מסויימת.
למשל אם פונקציה גם מכניסה למסד הנתונים וגם שומרת את הנתון לקובץ במקביל, בדוחק ניתן לקרוא לזה שיש לה מטרה אחת: שמירת הנתון. אבל פונקציה ששומרת למסד הנתונים וגם זורקת webhook שהנתון השתנה, עוברת על הכלל.
אבל לגיטימי לעבור על הכלל הזה מידי פעם. למשל כשהפעולה האחרת היא משנית מאוד, מצומצמת.
ולידציה בתחילת דרכה היא בהחלט פעולה משנית שנח לראות אותה יחד עם השמירה. אם הולידציה הופכת לתהליך, מוציאים את זה החוצה, זה שגרת יומו של מפתח טוב.
הרבה פחות לגיטימי לכתוב בלי להכיר טוב את השפה
מבחן טוב האם פונקציה עוברת על הכלל ברגל גסה הוא כשבאים לקרוא לה שם. אם יוצא שם טוב ונכון, בדרך כלל לא עברו על הכלל. אם השם לא נכון או לא מכסה חלק משמעותי מהפעולות, או שיוצא משפט ארוך (SaveAndRestoreAndNotify), אז ישנה בעיה...
@dovid לעצם החילוק שלך
אתה קצת נכנס לחלק שקלאס עושה אחריות אחת
פונקציה עושה דבר אחד, דבר אחד בלבד, ועושה אותו היטב
זה לכל הפחות מה שלימדו אותי בקשר לקלין קוד (וכך גם רושם אנשל בוב) (איתור חריגות וחוסרים אני יחלק ל2 עם פונקציה שקוראת לשניהם) -
@A0533057932 אני התייחסתי לעיקרון של פונקציה אחת - מטרה אחת, ובעיקר מתי זה כבר חריגה משמעותית מהכלל.
אני לא עובד בכלל עם העקרונות של clean architecture (שזה ספר ופרדיגמת פיתוח על איך לעשות מערכת, הclean code זה של הספר שלו ברמת הקוד) של הדוד בוב.
זה נכון שהזכרתי את SOLID, בטעות, שכחתי שזה ה"סט" שלו.
הוא מאוד טוב במיתוג ויצירת סלוגנים, ולכן השמות שייכים לו (הרעיון של פונקציה ממוקדת כמובן לא שלו, אולם אין לזה שום שם לפניו...), העקרונות שלו מאומצים ומיושמים במידה רבה בתעשיה, אבל אני בכלל לא "גדלתי על ברכיו". אני לא אוהב בכלל את הקיצוניות שלו, ואני חושב שהכללים שלו הם פאנטיים ומביאים בעיות משלהם.
על הclane architecture שמעתי רק לפני שנתיים בערך, וממש לא התחברתי ועם הזמן גם פיתחתי ביקורת של ממש לעקרונות שלו, מה שכולם אומרים ומסכימים שצריך לקחת אותו במידה ולא עד הקצה.
(מה שכן הכרתי ואימצתי זה הספר code complete שהוא בכלל מביע דעות אלא סך הכל מסכם מה עושה נזק ומה עושה תועלת באופן ודאי מהמציאות, וממנו שאבתי עקרונות קידוד, הרבה מהם היו תמיד בקונצנזוס אלא שצריך לשמוע עליהם פעם כדי לקלוט את הכלל). -
כיהודה ועוד לקרא, אבקש להאיר מספר נקודות, תוך הבהרה שאינני מתמצא דיי בתחום ובפרט לא בטרמינולוגיה המקצועית:
א. שאלה ב' אינה קשורה ישירות לכותרת או לשאלה א'. מדובר בשאלה כללית על עקרון הכימוס. ב-JavaScript מיישמים זאת לרוב באמצעות export (והגבלת גישה דרך מודולים), ואילו בשפות מבוססות מחלקות כגון C# הכימוס מובנה בצורה ישירה וברורה יותר באמצעות הגדרת רמות גישה (public, private וכו').
ב. השאלה הראשונה נוגעת לעקרונות קידוד. ברמה מופשטת, ניתן לראות בכך שאלה של פרקטיקה — מה עובד בצורה הטובה ביותר. אולם גישה נכונה מחייבת חשיבה לטווח ארוך: לא רק מה עובד כעת, אלא מה יאפשר ביצוע שינויים עתידיים בצורה יעילה ובטוחה.
יש לשאול:
מה ישרת אותי ואת המערכת בצורה מיטבית לאורך זמן?
מה יסייע בניווט בקוד ובהכנסת שינויים בצורה מסודרת?
מה יאפשר למערכת לבצע את ייעודה מבלי לייצר בעיות לוגיות או תלותיות מיותרות?אם נשתמש בדוגמה מעולמנו העכשווי: כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
ובשני מילים: "בהירות מודולרית"
ועוד הערה קטנה מותר לך להחליט מתי ליישם בהירות זו ומתי לא כל עוד שהחלטת כך במודע ולא מתוך עצלנות.
-
כיהודה ועוד לקרא, אבקש להאיר מספר נקודות, תוך הבהרה שאינני מתמצא דיי בתחום ובפרט לא בטרמינולוגיה המקצועית:
א. שאלה ב' אינה קשורה ישירות לכותרת או לשאלה א'. מדובר בשאלה כללית על עקרון הכימוס. ב-JavaScript מיישמים זאת לרוב באמצעות export (והגבלת גישה דרך מודולים), ואילו בשפות מבוססות מחלקות כגון C# הכימוס מובנה בצורה ישירה וברורה יותר באמצעות הגדרת רמות גישה (public, private וכו').
ב. השאלה הראשונה נוגעת לעקרונות קידוד. ברמה מופשטת, ניתן לראות בכך שאלה של פרקטיקה — מה עובד בצורה הטובה ביותר. אולם גישה נכונה מחייבת חשיבה לטווח ארוך: לא רק מה עובד כעת, אלא מה יאפשר ביצוע שינויים עתידיים בצורה יעילה ובטוחה.
יש לשאול:
מה ישרת אותי ואת המערכת בצורה מיטבית לאורך זמן?
מה יסייע בניווט בקוד ובהכנסת שינויים בצורה מסודרת?
מה יאפשר למערכת לבצע את ייעודה מבלי לייצר בעיות לוגיות או תלותיות מיותרות?אם נשתמש בדוגמה מעולמנו העכשווי: כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
ובשני מילים: "בהירות מודולרית"
ועוד הערה קטנה מותר לך להחליט מתי ליישם בהירות זו ומתי לא כל עוד שהחלטת כך במודע ולא מתוך עצלנות.
@pcinfogmach כתב בהבנת solid וclean code:
שאלה ב' אינה קשורה ישירות לכותרת או לשאלה א'. מדובר בשאלה כללית על עקרון הכימוס.
ראשית, תודה.
שנית. היא כן, היא נובעת ישירות ממנה. כנראה לא הבינו כוונתי.אם אנו מבינים שלפי עקרון הsolid והclean code, פונקציה עושה רק דבר אחד והולידציה היא מחוץ לחוק באותה פונקציה, אם כן זה פותח פתח לבעיות, הרי אם יש פונקציה רגישה, ואין עליה שום הגנה, מה ימנע ממני מלהשתמש בה לרעה? ובעצם:
כתב בהבנת solid וclean code:
ב. איך אני מונע ממישהו להתשמש בפונקצית הוספת ערך הכללית שכוללת את הולידציה וכו' ולא להשתמש בפונקצית ההוספה ישירות, דבר שבוא אסון למסד נתונים?
נכון יכולתי להסביר יותר, אבל הנחתי שעם השאלה הקודמת והכותרת ההקשר יובן.
@pcinfogmach כתב בהבנת solid וclean code:
כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
לענ"ד בלתי אפשרי לצערי... הם לא יודעים מימינם ומשמאלם.
@pcinfogmach כתב בהבנת solid וclean code:
ש לשאול:
מה ישרת אותי ואת המערכת בצורה מיטבית לאורך זמן?
מה יסייע בניווט בקוד ובהכנסת שינויים בצורה מסודרת?
מה יאפשר למערכת לבצע את ייעודה מבלי לייצר בעיות לוגיות או תלותיות מיותרות?אם נשתמש בדוגמה מעולמנו העכשווי: כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
ובשני מילים: "בהירות מודולרית"
ועוד הערה קטנה מותר לך להחליט מתי ליישם בהירות זו ומתי לא כל עוד שהחלטת כך במודע ולא מתוך עצלנות
ממקומות אחרים ומשאלה את הבינה מלאכותית נשמע שזה הסטנדרט וכך כותבים היום. עכשיו נשמע שלא?
-
@pcinfogmach כתב בהבנת solid וclean code:
שאלה ב' אינה קשורה ישירות לכותרת או לשאלה א'. מדובר בשאלה כללית על עקרון הכימוס.
ראשית, תודה.
שנית. היא כן, היא נובעת ישירות ממנה. כנראה לא הבינו כוונתי.אם אנו מבינים שלפי עקרון הsolid והclean code, פונקציה עושה רק דבר אחד והולידציה היא מחוץ לחוק באותה פונקציה, אם כן זה פותח פתח לבעיות, הרי אם יש פונקציה רגישה, ואין עליה שום הגנה, מה ימנע ממני מלהשתמש בה לרעה? ובעצם:
כתב בהבנת solid וclean code:
ב. איך אני מונע ממישהו להתשמש בפונקצית הוספת ערך הכללית שכוללת את הולידציה וכו' ולא להשתמש בפונקצית ההוספה ישירות, דבר שבוא אסון למסד נתונים?
נכון יכולתי להסביר יותר, אבל הנחתי שעם השאלה הקודמת והכותרת ההקשר יובן.
@pcinfogmach כתב בהבנת solid וclean code:
כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
לענ"ד בלתי אפשרי לצערי... הם לא יודעים מימינם ומשמאלם.
@pcinfogmach כתב בהבנת solid וclean code:
ש לשאול:
מה ישרת אותי ואת המערכת בצורה מיטבית לאורך זמן?
מה יסייע בניווט בקוד ובהכנסת שינויים בצורה מסודרת?
מה יאפשר למערכת לבצע את ייעודה מבלי לייצר בעיות לוגיות או תלותיות מיותרות?אם נשתמש בדוגמה מעולמנו העכשווי: כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
ובשני מילים: "בהירות מודולרית"
ועוד הערה קטנה מותר לך להחליט מתי ליישם בהירות זו ומתי לא כל עוד שהחלטת כך במודע ולא מתוך עצלנות
ממקומות אחרים ומשאלה את הבינה מלאכותית נשמע שזה הסטנדרט וכך כותבים היום. עכשיו נשמע שלא?
פוסט זה נמחק! -
@pcinfogmach כתב בהבנת solid וclean code:
שאלה ב' אינה קשורה ישירות לכותרת או לשאלה א'. מדובר בשאלה כללית על עקרון הכימוס.
ראשית, תודה.
שנית. היא כן, היא נובעת ישירות ממנה. כנראה לא הבינו כוונתי.אם אנו מבינים שלפי עקרון הsolid והclean code, פונקציה עושה רק דבר אחד והולידציה היא מחוץ לחוק באותה פונקציה, אם כן זה פותח פתח לבעיות, הרי אם יש פונקציה רגישה, ואין עליה שום הגנה, מה ימנע ממני מלהשתמש בה לרעה? ובעצם:
כתב בהבנת solid וclean code:
ב. איך אני מונע ממישהו להתשמש בפונקצית הוספת ערך הכללית שכוללת את הולידציה וכו' ולא להשתמש בפונקצית ההוספה ישירות, דבר שבוא אסון למסד נתונים?
נכון יכולתי להסביר יותר, אבל הנחתי שעם השאלה הקודמת והכותרת ההקשר יובן.
@pcinfogmach כתב בהבנת solid וclean code:
כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
לענ"ד בלתי אפשרי לצערי... הם לא יודעים מימינם ומשמאלם.
@pcinfogmach כתב בהבנת solid וclean code:
ש לשאול:
מה ישרת אותי ואת המערכת בצורה מיטבית לאורך זמן?
מה יסייע בניווט בקוד ובהכנסת שינויים בצורה מסודרת?
מה יאפשר למערכת לבצע את ייעודה מבלי לייצר בעיות לוגיות או תלותיות מיותרות?אם נשתמש בדוגמה מעולמנו העכשווי: כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
ובשני מילים: "בהירות מודולרית"
ועוד הערה קטנה מותר לך להחליט מתי ליישם בהירות זו ומתי לא כל עוד שהחלטת כך במודע ולא מתוך עצלנות
ממקומות אחרים ומשאלה את הבינה מלאכותית נשמע שזה הסטנדרט וכך כותבים היום. עכשיו נשמע שלא?
@eido כתב בהבנת solid וclean code:
כתב בהבנת solid וclean code:
ב. איך אני מונע ממישהו להתשמש בפונקצית הוספת ערך הכללית שכוללת את הולידציה וכו' ולא להשתמש בפונקצית ההוספה ישירות, דבר שבוא אסון למסד נתונים?
אתה כמובן משתמש בקלאסים וכך יש לך פונקציית הכנסה חיצונית
שהיא רק קונטרולר כלומר שורה ראשונה קוראת לפונקציה או קלאס של ולידציה שורה שניה קוראת לפונקציה או קלאס של הכנסה@pcinfogmach כתב בהבנת solid וclean code:
כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
לענ"ד בלתי אפשרי לצערי... הם לא יודעים מימינם ומשמאלם.
אין לי מושג מול מי השתמשת אבל היום הAI יודעים טוב מאד מה היא פונקציה טובה ומה לא והם יודעים לתת צינוים לכל פונקציה
ויודעים לשפר קוד שנכתב עם כללים וסדר ברור בלי ליצור בלאגן בכלל@pcinfogmach כתב בהבנת solid וclean code:
ש לשאול:
מה ישרת אותי ואת המערכת בצורה מיטבית לאורך זמן?
מה יסייע בניווט בקוד ובהכנסת שינויים בצורה מסודרת?
מה יאפשר למערכת לבצע את ייעודה מבלי לייצר בעיות לוגיות או תלותיות מיותרות?אם נשתמש בדוגמה מעולמנו העכשווי: כיצד נכתוב קוד שיהיה ברור ומובנה עד כדי כך שגם כלי בינה מלאכותית יוכלו לנתח ולתחזק אותו מבלי ליצור חוסר סדר.
ובשני מילים: "בהירות מודולרית"
ועוד הערה קטנה מותר לך להחליט מתי ליישם בהירות זו ומתי לא כל עוד שהחלטת כך במודע ולא מתוך עצלנות
ממקומות אחרים ומשאלה את הבינה מלאכותית נשמע שזה הסטנדרט וכך כותבים היום. עכשיו נשמע שלא?
זה אכן הסטנדרט הנפוץ ביותר לקוד שיתופי כי כך ניתן לתחזק אותו במקביל ובזמנים שונים
לכתוב פונקציה אחת גדולה שעושה הכל זה נהדר בהתחלה כל עוד אתה המתחזק היחיד והיא לא רמורה להשתנות לעולם
