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

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

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

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

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

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

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

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

name = payload[:name] || payload['name']

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

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

אלכס קונדוב כותב:

Writing code by hand gave me the pace of thought I needed to understand a problem deeply. After a couple of years at a company, I knew the codebase by heart, every corner of it, every service, and every script.

I find it difficult to say the same thing now.

ומביא אותנו לשאלה מהכותרת: "מה צריך בשביל להבין"?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אם גם אתם שמעתם דברים דומים בבקשה קחו אוויר. בעבודה עם ג'וניורים הבעיה שלנו היא עודף שימוש בכלי AI:

1. ג'וניורים נותנים ל AI לכתוב קוד ושולחים PR בלי להבין מה בוצע.

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

3. ג'וניורים לא עצרו לחפש פתרונות יעילים יותר ולא השוו בין מספר אופציות.

4. ג'וניורים לא ראו את בעיות האבטחה שהם הכניסו למערכת.

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

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

אתם כבר מכירים את gitignore ואת .git/info/exclude וזוכרים את הבעיה המעצבנת בשניהם: מנגנון ההתעלמות מאפשר להתעלם מקבצים קיימים על הדיסק שאינם בריפו. אבל מרגע שקובץ נמצא בריפו לא משנה כמה פעמים תכתבו אותו ב gitignore השינויים בו תמיד יופיעו ב status. קובץ שנמצא במעקב עוקף את ה gitignore.

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

התשובה נקראת skip worktree bit ואפשר לקרוא עליה בדף התיעוד man git-update-index. בקצרה זה מתג שנשמר מקומית אצלכם ואומר לגיט לשמור על השינויים המקומיים שלכם כל עוד אפשר. אנחנו מדליקים אותו לקובץ מסוים עם:

git update-index --skip-worktree docker-compose.yml

ומבטלים עם:

git update-index --no-skip-worktree docker-compose.yml

דוגמה? בטח. ניצור ריפו עם שני קבצים:

$ git init .
$ date > a.txt
$ date > b.txt
$ git add .
$ git commit -m 'initial commit'

עכשיו נשנה את b.txt ונראה בסטטוס את השינוי:

$ date > b.txt
ynonp@ynons-MacBook-Air ~/tmp/blog/skipworktree (main*) $ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

נדליק את skip worktree bit:

$ git update-index --skip-worktree b.txt
ynonp@ynons-MacBook-Air ~/tmp/blog/skipworktree (main) $ git status
On branch main
nothing to commit, working tree clean

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

$ git restore b.txt
error: pathspec 'b.txt' did not match any file(s) known to git

ב ls-files לעומת זאת הקובץ כן מופיע:

$ git ls-files
a.txt
b.txt

ואם נוסיף -v נוכל לראות שהוא במצב S כלומר skip-worktree:

$ git ls-files -v
H a.txt
S b.txt

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

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

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

איך ניגשים לזה?

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

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

I'm building a TODO editor allowing users to create todos items, edit todos, delete todos and reorder todos in the list with optimistic updates.

When users perform multiple actions before server had a chance to update the system has strange bugs, for example: 

1. trying to edit a todo that wasn't yet created 2. trying to reorder todos when server state is different than the optimistic state

Suggest 4 possible architectures to combine optimistic updates and editing, order from simple to complicated. For each architecture explain what API calls are made and when and how it deals with user editing faster than server updates

ואתם יכולים לראות את השיחה כאן: https://chatgpt.com/share/696e35f8-9d68-8009-a35a-26169c8ccbe9

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

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

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

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

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

4. הנאה - אין הרבה כיף בלכתוב פתרון עם באגים שעובד פחות טוב ממה ש AI היה כותב או להגיד ל AI "טוב תבנה את הדבר הכי פשוט" ולהגיש.

אם אין לכם זמן לכתוב מימוש נכון, איפה תמצאו זמן לכתוב את המימוש פעמיים?

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

רגע, מה?

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

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