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

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

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

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

והכי גרוע - כן אנחנו כותבים בדיקות אבל עדיין יש באגים.

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

הפונקציה os.path.join של פייתון מחברת שמות של כמה נתיבים לנתיב גדול:

>>> import os
>>> os.path.join("/foo", "bar", "buz")
'/foo/bar/buz'

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

>>> import urllib.parse
>>> urllib.parse.urljoin("http://localhost", "blog", "items")
'http://localhost/blog'

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

>>> urllib.parse.urljoin('http://localhost/blog', 'items')
'http://localhost/items'

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

>>> urllib.parse.urljoin('http://localhost/blog/', 'items')
'http://localhost/blog/items'

גם JavaScript תומכת בחיבור URL-ים רק משני חלקים, אבל שם סדר הפריטים הפוך:

> new URL("items", "http://localhost/blog").toString()
'http://localhost/items'
> new URL("items", "http://localhost/blog/").toString()
'http://localhost/blog/items'

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

3.1.1 :006 > URI.join("http://localhost", "blog/", "items").to_s
 => "http://localhost/blog/items"

3.1.1 :007 > URI.join("http://localhost", "blog", "items").to_s
 => "http://localhost/items"

וגם קלוז'ר במימוש של ספריית lambdaisland/uri תואמת להתנהגות של רובי עם הלוכסנים בסוף מילים:

; "http://localhost/items"
(str (uri/join "http://localhost" "blog" "items"))

; "http://localhost/blog/items"
(str (uri/join "http://localhost" "blog/" "items"))

מסקנות -

1. שימו לב לחתימה של URI/join בשפה שבחרתם, האם אפשר לקבל כמה פרמטרים שרוצים או רק שניים ומה הסדר שלהם.

2. שימו לב שבחיבור נתיבים ל URL יש לסיים בלוכסן כל נתיב שאתם רוצים שיישאר בתוצאה הסופית.

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

כולנו מכירים את מנגנון ה format string של פייתון שמאפשר לכתוב f בתחילת מחרוזת כדי "לשתול" בתוך המחרוזת תוצאות של ביטויים בקוד פייתון לדוגמה:

print(f"10 / 3 = {10 / 3}")

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

>>> print(f"{10 / 3:.2f}")
3.33

ויש עוד למשל אפשר להפוך מספר לבסיס 16 אם נכתוב אחרי הנקודותיים את האות x:

>>> print(f"16 is base 16 is {16:x}")
16 is base 16 is 10

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

>>> format(16, 'x')
'10'
>>> format(10 / 3, '.2f')
'3.33'
>>> format('hello', '^20s')
'       hello        '

שזה לא תמיד יותר קצר מ f"..." אבל יש בו משהו יותר מדויק כשעובדים על ערך בודד.

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

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

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

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

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

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

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

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

הנה כמה דברים כלליים שאנחנו יודעים על סוף יום העבודה-

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

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

3. אחרי שיש פיתרון עובד אנחנו לא אוהבים לבזבז זמן על לבדוק אותו ומעדיפים לעבור לבעיה הבאה.

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

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

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

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

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

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

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

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

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

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