הבלוג של ינון פרק

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

זה לעתים נדירות המקרה.

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

זה לא סתם שכל Front End Framwork שהיתה בשכונה מספיק זמן עברה אינסוף סבבי Refactoring ובשלב מסוים גם כתיבה מחדש מאפס. באנגולר זה קרה במעבר מגירסה 1 ל-2, בריאקט במעבר מגירסה 15 ל 16 ובויו זה היה המעבר ל Vue3. אנחנו יכולים לקשקש עד מחר על Design Patterns וכתיבה נכונה, אבל בסוף כשמערכת פוגשת את העולם דברים משתנים.

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

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

כל יום יש אינסוף פיצ'רים שדחוף לסיים ובגללם היום לא מצאתי זמן ל Refactoring.

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

כל חודש יש אינסוף משימות דחופות שלא השאירו לי זמן ללמוד מיומנות חדשה.

וכל שנה יש אינסוף ישיבות מיותרות שלא השאירו לי זמן ליצור קשרים אמיתיים עם אנשים מחוץ לחברה.

ועדיין-

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

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

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

ואם נצליח במהלך השנה ליצור קשרים משמעותיים עם אנשים מחוץ לחברה, לאורך זמן יהיו לנו הרבה יותר אנשים להחליף איתם רעיונות יצירתיים ויהיה לנו הרבה יותר קל לבנות מסלול קריירה שמתאים לנו.

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

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

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

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

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

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

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

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

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

aaaabbccc

אז אנחנו מחליפים את רצף ה a-ים ב a4, את רצף ה b-ים ב b2 ואת רצף ה c-ים ב c3 ומקבלים:

a4b2c3

אם התוצאה ארוכה יותר מהמחרוזת המקורית יש להחזיר את המחרוזת המקורית, ואם התוצאה קצרה יותר יש להחזיר את התוצאה המכווצת.

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

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

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

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

האם הוא פותר בעיות מהר?

האם הוא רואה את כל מקרי הקצה הרלוונטיים?

האם הפיתרונות שלה תמיד הכי יעילים?

האם התקשורת איתה טובה?

האם הוא יתאמץ לפתור בעיה בכוחות עצמו?

האם הוא ידע לבקש עזרה כשצריך?

האם היא תסכים ללמוד טכנולוגיה חדשה כשהפרויקט דורש את זה?

האם היא לומדת מהר?

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

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

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

בפוסט היום אני רוצה לכתוב שרת GraphQL ב Node.JS ו Express כדי לראות איך זה עובד. הפרויקט הוא API למערכת ניהול משימות שמאפשר לנו לראות את המשימות הפתוחות במערכת ולעדכן סטטוס "בוצע" של כל משימה.

העליתי את כל הקוד בפוסט לפרויקט דוגמה בגיטהאב בקישור:

https://github.com/ynonp/express-graphql-demo