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

שני דברים שמשפיעים מאוד על הפרודוקטיביות שלנו כמפתחים הם:

1. שיטות העבודה, הנהלים, התבניות וכל ההרגלים "האוטומטיים" איתם אנחנו עובדים.

2. הכלים בהם אנחנו משתמשים, שעוזרים לנו ליישם את שיטות העבודה הטובות שלנו.

והסדר בין השניים חשוב.

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

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

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

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

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

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

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

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

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

4. אולי אני יכול ליצור Fork לספריה ולהוסיף לקומפוננטה מבפנים את המנגנון שאני צריך (בתקווה בלי לשבור שום דבר אחר).

5. אולי אני יכול להשתמש בקומפוננטה מקבילה מספריית UI אחרת.

6. אולי אני יכול לשנות את כל היישום שלי כך שישתמש בספריית UI אחרת שבה הקומפוננטה מתנהגת כמו שאני רוצה.

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

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

את אותו הגיון הרבה יותר קשה ליישם בקוד.

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

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

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

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

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

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

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

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

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

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

• תעודות SSL (טירוף)

• זיהוי תמונה (הבדיחה הזאת למשל כבר לא רלוונטית)

• להרים שרת בענן

• פיתוח ממשק משתמש חוצה פלטפורמות

• העברת קוד כולל כל התלויות ממכונה למכונה (היוש דוקר)

• הקמת תשתית CI/CD מלאה בחינם (היוש גיטהאב)

• יישומי ווב בזמן אמת (זוכרים כשהצ'ט בג'ימייל היה נראה כמו הברקה טכנולוגית?)

• זירו דאונטיים דיפלוימנטס

• למרכז דברים ב CSS

• תמיכה בדפדפנים ישנים (כן היה פעם דבר שנקרא IE)

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

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

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

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

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

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

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

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

בפוסט ארבע תבניות לקומפוננטות React מתורגמות ל ClojureScript ו Reagent הראיתי איך לעבוד עם ריאייג'נט ולכתוב קומפוננטות ריאקט ב clojurescript. הדוגמה האחרונה באותו פוסט, וזו שבגללה שמרתי מרחק מריאייג'נט בשנתיים האחרונות היתה דוגמה לתקשורת ajax. היא היתה שונה מקוד שאני רגיל לכתוב בריאקט, ואולי בגללי ואולי בגלל ריאייג'נט עבדה פחות טוב מקוד ג'אווהסקריפט מקביל שהייתי כותב. הקושי העיקרי שלי בתרגום הקוד מ JavaScript לריאייג'נט היתה חוסר התמיכה ב Hooks, ובפרט useEffect שהיה לי מאוד חסר.

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

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

בואו נניח שאתם צריכים לכתוב קוד שקורא url-ים של דוקרהאב ומדפיס את שם המחבר ושם הריפו מה url. כלומר אתם תתנו לו את המחרוזת:

https://hub.docker.com/r/bitnami/postgresql

והקוד יחזיר את המילון:

{ 'author': 'bitnami', 'repo': 'postgresql' }

יודעים מה? עזבו, הנה חסכתי לכם את המאמץ, זאת הפונקציה:

import re
import sys

def parse_dockerhub_url(url: str):
    res = re.search(r'https://hub.docker.com/r/([\w%-]+)/([\w%-]+)', url)
    if res:
        author, repo = res.groups()
        return { 'author': author, 'repo': repo }

print(parse_dockerhub_url(sys.argv[1]))

כולם מרוצים הקוד הגיע לפרודקשן ואז לקוח גדול מתקשר להתלונן על באג. מסתבר שאצלם משתמשים הרבה ב Official Images, שזה אימג'ים שה url שלהם נראה ככה:

https://hub.docker.com/_/ubuntu

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

מה עושים?

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

import re
import sys

def parse_dockerhub_url(url: str):
    res = re.search(r'https://hub.docker.com/r/([\w%-]+)/([\w%-]+)', url)
    if res:
        author, repo = res.groups()
        return { 'author': author, 'repo': repo }

    res = re.search(r'https://hub.docker.com/_/([\w%-]+)', url)
    if res:
        author, repo = ["Official Image", res.group(1)]
        return { 'author': author, 'repo': repo }



print(parse_dockerhub_url(sys.argv[1]))

זה עובד ואפשר להמשיך לתקלה הבאה.

כן?

רגע.

אומנם תיקנתם את הבאג אבל נראה לי ששברתם את הפונקציה.

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

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

ועם כל זה אני חושב שיש פה רק שתי אפשרויות שיעבדו לטווח הרחוק:

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

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

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

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

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

הכלי kubectl משתמש בקובץ קונפיגורציה ברירת מחדל שנמצא בנתיב ~/.kube/config. בתוך אותו קובץ יש הגדרות כמו לדוגמה:

apiVersion: v1
clusters:
- cluster:
    server: https://cimaks-dns-bca70ca9.hcp.westeurope.azmk8s.io:443
  name: cimaks
contexts:
- context:
    cluster: cimaks
    user: clusterUser_Playground_cimaks
  name: cimaks
current-context: cimaks
kind: Config
preferences: {}

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

apiVersion: v1
clusters:
- cluster:
    server: https://146.148.56.200:443
  name: cloud_okteto_com
contexts:
- context:
    cluster: cloud_okteto_com
    extensions:
    - extension: null
      name: okteto
    namespace: ynonp
    user: 6b5b39bc-9c83-4d7b-a345-b03922c7e979
  name: cloud_okteto_com
current-context: cloud_okteto_com
kind: Config
preferences: {}

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

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

$ export KUBECONFIG=~/.kube/config:~/Downloads/okteto-kube.config

ועכשיו הפקודה:

$ kubectl config get-contexts

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

CURRENT   NAME               CLUSTER            AUTHINFO        NAMESPACE
*         cimaks             cimaks             
          cloud_okteto_com   cloud_okteto_com                   ynonp

מההדפסה אני רואה שפקודת ה kubectl הבאה שאכתוב תגיע לקלאסטר cimaks כי הוא מסומן בכוכבית. הפקודה use context בוחרת את הקונטקסט הפעיל ולכן אני יכול לשנות קלאסטר עם:

$ kubectl config use-context cloud_okteto_com

ועכשיו כל פקודת kubectl שאכתוב תפעל על הקלאסטר השני.