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

קומפוננטות צד שרת ב node יכולות לעשות דברים מופלאים, למשל לקרוא קובץ ממערכת הקבצים ולהציג אותו בקלות על המסך או לקרוא מידע מבסיס הנתונים. הבעיה מתחילה כשנתוני צד השרת האלה מתעדכנים. פעם כשהיתה לנו קומפוננטת צד לקוח שקראה את המידע עם react-query ידענו לרענן את המידע כל כמה שניות או לבנות Web Socket כדי לקבל עדכון מהשרת כשהמידע מתעדכן. בפוסט היום נראה דוגמה קצרה איך לעשות דבר דומה ובקלות בקומפוננטות צד שרת.

יום 7 של Advent Of Code לא היה מסובך והזכיר לי כמה כיף שאפשר ברובי לשנות את המחלקות המובנות בשפה. בואו נראה מה היה שם.

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

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

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

אבל ה AI לא כתב. זה אתה כתבת. ובכל מקרה ה AI לא יצליח לתחזק את זה.

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

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

מה כן?

1. מתכננים בעצמנו איך דברים צריכים להיראות ולעבוד (הארכיטקט זה אתה).

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

3. מנקים ומארגנים מחדש את הקוד למבנים הגיוניים שאנחנו נוכל לתחזק אחרי שה AI מסיים לירות.

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

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

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

מקור בטוויטר https://x.com/mjackson/status/1904977249918705853

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

1. ללכת נגד הזרם בפריימוורק זה מאתגר, כי גירסאות חדשות של ריאקט רק יעשו את זה יותר קל לעבוד עם Server Components ויותר קשה לעבוד בלי. ראינו את זה כשהכניסו את Hooks. לאט לאט הדוגמאות ברשת והאקוסיסטם יתאימו לסטנדרט שמכתיבים ה Core Developers של ריאקט.

2. יכול להיות שיש אתגר טכני בשילוב Server Components ב Remix. יכול להיות שיש מקור אחר להתנגדות. בכל מקרה ככל שהם יפתחו פרדיגמת עבודה שלהם אנחנו כמפתחים נצטרך ללמוד את שתי שיטות העבודה לפחות בעתיד הקרוב.

3. יכול להיות שיהיו דרכים לחבר בין Server Components ל React Router. דוגמה אחת שמצאתי היא הפוסט הזה:

https://www.buszewski.com/writings/2024-12-23-react-router-7-has-server-components/

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

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

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

https://convospanish.com/spanish-expressions-with-leche/#SerlaLeche

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

שלחתם Pull Request לפרויקט שזז מהר. עד שהבן אדם בצד השני הספיק לשלוח הערות השינוי שלכם עכשיו 4 גירסאות מאחור. בשביל שיהיה מסודר אתם עושים ריבייס לגירסה הכי חדשה ו - הפתעה, גיטהאב מציג את ה diff בין הגירסה שלכם לגירסה מולה יצרתם את ה Pull Request כשהתחלתם. כלומר כל השינויים ב main שקרו באותם 4 קומיטים שנכנסו אליכם לגירסה (כי עשיתם את הריבייס) מופיעים עכשיו כחלק מה diff של הגירסה שלכם ב Pull Request.

מה עושים?

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

Are you sure you want to change the base?

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

שאלה אמיתית - אתם מרגישים שאתם מרגישים יותר מדי או פחות מדי ב AI? ואם פחות מדי, למה אתם לא משתמשים בו יותר? הנה רשימת המקרים בהם אני משתמש ב AI במהלך הפיתוח ו Best Practices שמצאתי לכל מקרה:

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

2. כשאני כותב קוד ויודע מה אני רוצה - אם אני בונה סכימה לדריזל ואני יודע איזה טבלה אני רוצה ואיזה עמודות זה זמן מושלם ללחוץ Command I ב VS Code ולבקש מ Copilot לכתוב את הבלוק שמוסיף את הטבלה לסכימה, וכך חוסך לי לבדוק מה השם המדויק של הפונקציה.

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

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

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

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

7. כתיבת תיעוד, בדיקות והודעות קומיט.

8. קבלת Code Review - לפני קומיט אני מפעיל git diff ושולח את הפלט ל AI כדי לקבל סיכום מסודר של מה שעשיתי והצעות לשיפור או תיקונים.

ומה אתכם? באיזה מצבים אתם משתמשים או לא משתמשים ב AI? ואם הייתם רוצים להשתמש יותר, מה הסיבות המרכזיות בגללן אתם עדיין מקודדים בלעדיו?

נ.ב. הג'מיני החדש באמת מטורף.

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

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

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

fibonacci = lambda n, a=0, b=1: [a := b, b := a + b][0] if n else None

נראה יופי אבל כמו התורמוס, התוצאה אינה מספר מסדרת פיבונאצ'י.

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

from functools import lru_cache

fib = lru_cache(None)(lambda n: n if n < 2 else fib(n-1) + fib(n-2))

print(fib(10))  # Output: 55

ואז הצעה נוספת ש"משתמשת באיטרציות כדי לשפר ביצועים":

fib = lambda n, a=0, b=1: a if n == 0 else fib(n-1, b, a+b)

print(fib(10))  # Output: 55

ואתם צודקים, אין פה איטרציות ובהשוואה ל LRU Cache גם אין פה שיפור ביצועים.

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

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