האם מהירות ואיכות סותרים אחד את השני בכתיבת קוד?

אמ;לק: לא. והנה כמה טיפים שיעזרו לכם

מקור: Pixabay, עיבוד תמונה

מאת קובי מזרחי

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

Best practices – דרך תבניות

עקביות בתהליך פיתוח הקוד לאורך זמן היא הבסיס לפיתוח איכותי. על מנת להגיע לפיתוח איכותי אנו משתמשים ב-Plop, חבילת npm קטנה ומאוד שימושית. Plop מאפשרת לנו לייצר קבצים חדשים לפי תבניות שהגדרנו מראש כסטנדרט לקוד איכותי, או להזריק קוד לאזורים מוגדרים בקבצים קיימים. כך אנחנו מייצרים את רוב הקבצים החדשים שלנו, מייצור components שיוצאות עם המבנה הבסיסי, קישור לקובץ ה-css שלהן, שלד של קובץ test ייעודי, ועד לכתיבת reducers, api-routes, service actions וכו’.

בצורה זו כל קוד חדש שנכנס שמרגיש ״תבניתי״ או ״ליניארי״ מבחינה טכנית יהיה בתצורה שאנחנו רואים בה הנכונה ביותר עבור החברה ובעיקר אחיד, ומבלי הצורך להגדיר תלויות בין הקבצים שוב ושוב. בנוסף לכך, כל קובץ חדש הנוצר במערכת, דרך Plop, מלווה בקובץ Test שהגדרנו, בתבנית שמיועד להיכשל אלא אם ייערך, דבר שאילץ אותנו לכתוב testing לכל חלק חדש במערכת ומעלה את אחוזי הכיסוי.

פורמטרים (Formatters)

אנחנו משתמשים באופן תמידי ב-Prettier. זהו Code formatter, שבכל שמירה של הקוד אוכף סגנון קוד נקי, כמו שבירת שורות ומחיקת whitespaces מיותרים, ריווח נכון ואחיד, שמירה על אחידות בסימון (כמו החלפת ‘ ב-” או הוספה/ הסרת סוגריים), וידוא סטנדרטי כתיבה שקבענו לו מראש, ובשורה התחתונה עושה לנו סדר בקוד.

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

לינטרים (Linters)

כשאומרים Linter בדרך כלל הדבר הראשון שעולה לראש הוא שמירה על עיצוב, בערך כמו שתיארתי שהשגנו בעזרת ה-Prettier, אבל מדובר בהרבה יותר מזה. Linter עוזר לנו לעלות על שגיאות, או דברים שעלולים להיות מסוכנים – משתנים עם שגיאות כתיב, כאלו שלא הוכרזו, או כאלו שלא נעשה בהם שימוש.  Linter מונע מאתנו מלהתעלם מטיפול בשגיאה במקרה של אחת ב-callback, מתריע על שורות console או debugger סוררות, וגורם לנו לעבוד על פי best practices שהגדרנו ועוד.

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

תהליך מתאים

כמו כל דבר מורכב, גם תהליך היצירה דורש חשיבה על התהליך הנכון עבורכם. אנו מצאנו את הדרך שמתאימה לאופי ההתקדמות שלנו. בחברה אנחנו מוכוונים impact, וככאלה, יוצא לנו לבצע deployment ל-Production עשרות פעמים ביום, משמע שכל מיזוג אל master משמעו העלאה ל-Production. זה דבר מדהים כשמדובר במהירות תגובה ודינאמיות של המוצר אך מביא איתו גם כמה אתגרים שגרמו לנו לבצע התאמות בתהליך הפיתוח – אנחנו שואפים שרמת חוסר הוודאות תהיה נמוכה ככל שניתן. כדי להשיג זאת אנחנו משתדלים שכל הכנסה של קוד חדש תהיה תכופה אך בכמות קטנה בכל פעם, מעין פיסות קטנות אך הדוקות ובדוקות של קוד שעולות אחת אחרי השניה – מה שאומר שפיצ׳ר יכול להיות מחולק לכמות לא קטנה של הכנסות קוד (כ-branches) שכל אחת מהן היא סוג של mvp מיניאטורי. לכל אחת מהן, קטנה ככל שתהיה, אנחנו מבצעים Code review עם לפחות חבר צוות אחד, ולאחר אישור היא תמשיך לאורך ה-pipeline ותעלה ל-production. לעיתים קרובות נעלה ״קוד רדום״ למערכת, שלאו דווקא המשתמש יראה או יוכל לחוות, אך זה יעזור ל-code review הבא להיות מתומצת ומובן יותר – הרבה יותר קל להשתלט על כמות קוד קטנה, או להחזיר לאחור במידת הצורך.

ניתוח קוד סטטי

מעבר לתהליך הפיתוח עצמו, עם חלק מהאתגרים שהועלו בחלק הקודם אנחנו מנסים להתמודד גם בתהליך ה-CI/CD.

מעבר לבדיקות build והרצת הטסטים השונים, חלק מתהליך ה-CI/CD שלנו כולל ניתוח קוד סטטי בעזרת כלי בשם Code climate. הכלי החביב הזה סורק ומוודא את בריאותו של הקוד שלנו – החל מהתראה על פונקציות בעלות אורך בעייתי או כפל קוד וכלה בדירוג רמת המורכבות של הקוד החדש שהכנסנו. מתריע אם ישנה ירידה ביעילות, סיכוני אבטחה ועוד. הוא מתריע, “צובע” את האזורים הבעייתים, ובדומה לשאר השלבים בתהליך ה-CI/CD הוא שיעביר או יכשיל את תהליך deployment אלא אם יעמוד בסטנדרטים שקבענו.

פורמטים יעילים

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

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

ניתוחי ביצועים

דבר שנכון לעשות הוא להריץ את המוצר בכליי אנליזה לבדיקת ביצועים – מניתוח זמני טעינה, שימוש בקבצים זללניים, זמני תעבורה, ועד למציאת צווארי בקבוק בביצועי המערכת. בכל פעם שאנו מבצעים זאת, אנו מגלים עולם חדש של אופטימיזציות שלפעמים גם ישפיעו לאחור ויגרמו לעדכון כליי הניתוח או ה-linters שלנו, ומשם להשתפר ולהשתכלל בכל פעם. להריץ ניתוח יזום בכל פעם שאנחנו מרגישים שמא יש ירידה בביצועים או פשוט בכדי לבצע וידוא שלא פגענו בדבר הינו רחוק מאידיאלי, זה משהו שאנחנו עובדים עליו ומנסים לשפר. כרגע אנו בוחנים כמה כלים שיוכלו להכנס כחלק מתהליך ה-CI/CD שלנו ולנתח ביצועי מערכת אחרי כל שינוי שמנסה להכנס ל-production, וכמובן להתריע במקרה של ירידה בביצועים.

יומנו של קפטן

ב-monday.com אנו דוגלים בשקיפות. וככאלה, אחד הדברים האהובים עלינו הוא לעדכן בנוגע לדברים שחידשנו. אז פתחנו שיחה במערכת בשם Captains log, שכל מחלקה, אנשי תחום או עיסוק מעדכנים בעת הצורך בנוגע לחידושים. זו פלטפורמה מצויינת לאנשי הפיתוח לעדכן את שאר אנשי החברה בפיצ’רים חדשים שהם העלו (ולחזק את תחושת ההישגיות), אך גם לעדכן בתוך קרב אנשי ה-R&D בנוגע למסקנות, שיטות חדשות, המלצות לפיתוח או תשתיות שבנו ששאר החברים יוכלו להשען עליהן. כי אין דבר מרגיז יותר מלגלות אחרי כתיבת קוד מורכב, שמישהו אחר בנה תשתית שיכלה לחסוך לך את כל העבודה.

שבירת שגרה

כולנו נשאבים לשגרה, זה טבעי. לכן אחד הדברים המועילים ביותר שמצאנו היה, אחת לכמה זמן, פשוט לשבור אותה – ואם אפשר בו בזמן להזיז את המחט במונחים של impact הרי זה משובח! אז יצרנו מופעים מרוכזים, האקתונים, כמו למשל Column Hackathon, בו בעזרת תשתית שהוכנה מראש (שהתבססה גם על תבניות plop שציינו למעלה) חברי ה-R&D הצליחו לייצר ביום אחד כ-20 עמודות חדשות במערכת. מופע אחר היה Foundations week, שבוע בו עבדנו על תשתיות המערכת – שיפורי ביצועים, אבטחה, שיפור טסטים, שדרוגי כלים ועוד. דברים שביום יום לפעמים יכולים לזוז הצידה לטובת התקדמות מהירה ומהלך השבוע הזה קיבלו יחס הולם, והשינוי היה מורגש באופן מיידי.

דשבורדים דשבורדים דשבורדים

בפעם הראשונה שנכנסתי למשרדים שלנו והסתכלתי על הקירות, חשבתי לעצמי ״זו כמות מסכים שלא תבייש חדר שליטה של נאס״א״, ומהר מאוד הבנתי כמה ערך יש בזה, להיות מוכווני נתונים. אנחנו משתדלים לנטר ולנתח כל דבר שניתן למדוד – לכל אנשי תחום יש סט של דשבורדים שהם בנו לעצמם, מהסיילס, ל-HR ,CS, מרקטינג, R&D, כולם! מאחוזי שימוש בפיצ׳רים, כמות לקוחות רשומים, חוויות משתמש, דיווחי תקלות של משתמשים, וזמני התגובה שלנו, ועד להיבטים הטכניים: ניטור וניתוח כל אחת מהתשתיות שאנחנו עובדים איתה, דיווחי שגיאות, נתוני שרתים, טסטים ואחוזי כיסוי, deploys, מצב בריאות המערכת ועומסים, ועוד רבים וטובים. היכולת לנתח ולשפר, או לחלופין להיות עירניים לדברים שצריכים את תשומת ליבנו בזמן אמת הוא קריטי כדי לפעול ולהגיב מהר מכל היבטי החברה.

שיתוף ידע

אם בתרבות עסקינן, דבר נוסף שעזר לנו לשמור על איכות הקוד הוא קיום מפגשים סדירים בין אנשי ה-R&D. אנו מקפידים לקיים מפגשי Tech talks שבועיים, בהם בכל פעם מישהו אחר מעביר סדנה קצרה של פחות משעה, על Best practices בתחום מסוים, בין אם בטכנולוגיה ספציפית, גישה או מודול שכתב שכדאי שכולם יכירו, והערך בזה הוא אדיר. לאחר שראינו שהמודל הזה עובד, וכמובן כשבירת שגרה נחמדה, הרחבנו את היריעה, ולאחרונה הכרזנו על Professional week – שבוע פנימי של ה-R&D שבו כל בוקר ייפתח בהרצאה, בין אם של אחד המפתחים שלנו, ובין אם של מרצה אורח במטרה להעשיר את כולנו.

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

הכותב הוא מפתח Full Stack ב-monday.com

כתב אורח

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

הגב

3 תגובות על "האם מהירות ואיכות סותרים אחד את השני בכתיבת קוד?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
אחד שיודע
Guest

כתבה על רמה!

אבי
Guest

אחלה כתבה

Arnon Axelrod
Member
אני מסכים בהחלט עם התמה המרכזית של הכתבה ועם חלק גדול ממה שרשום בה, אבל לטעמי יש פוקוס גדול מדי, בעיקר בתחילת הכתבה, על כלים ועל שיטות יחסית שטחיות, בעוד שחסרים בה נושאים שלדעתי הרבה יותר חשובים על מנת לשמור על איכות ומהירות בו זמנית: 1. Root cause analysis לכל בעיה ושיפור מתמיד. הרעיון הוא למצוא באופן שוטף ואקטיבי דרכים *למנוע* טעויות, כדי לא לבזבז זמן אח”כ בחיפוש ותיקון 2. עם הזמן הקוד תמיד נוטה להתבלגן ולכן חשוב מאוד לעשות ריפקטורינג לעיתים תכופות. כמה תכופות? ממש באופן שוטף. הבעיה העיקרית היא שלרוב המפתחים אין את הידע והמיומנות כדי לעשות את… Read more »
wpDiscuz

תגיות לכתבה: