שלום אורח התחבר

כן, לשכתב. אבל חכם.

נושאים:יומי

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

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

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

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

  1. מידע - איזה מידע המנגנון שומר ב DB? איך יהיה אפשר להעביר את המידע כך שישמר במקום אחר? אני מאוד אוהב את הארכיטקטורה של Rails Active Storage בהיבט הזה, שמאפשרת לעבור בקלות בין מקומות אחסון.

  2. קשר עם מנגנונים אחרים במערכת - ככל שיש לי שכל לבנות מנגנונים שה API שלהם לשאר המערכת ברור כך יהיה יותר קל להחליף את הכל. בהיבט הזה כלל טוב הוא לא להשתמש ביותר מנקודה אחת בביטויים שלנו, כלומר להיזהר מקוד שנראה כך:

items[1].name.first

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

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

  2. בדיקות, בדיקות ובדיקות. ככל שיש לנו יותר בדיקות מסוג System Tests או Integration Tests על הפיצ'ר, כך אנחנו מרגישים יותר בטוחים כשמגיע הרגע לשכתב.

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

מעדיפים לקרוא מהטלגרם? בקרו אותנו ב:@tocodeil

או הזינו את כתובת המייל וקבלו את הפוסט היומי בכל בוקר אליכם לתיבה:


נהניתם מהפוסט? מוזמנים לשתף ולהגיב