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

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

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

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

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

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

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

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

הקטע הבא מועתק מתוך התיעוד של next.js:

import { cookies } from 'next/headers';

export default function AddToCart({ productId }) {
  async function addItem(data) {
    'use server';

    const cartId = cookies().get('cartId')?.value;
    await saveToDb({ cartId, data });
  }

  return (
    <form action={addItem}>
      <button type="submit">Add to Cart</button>
    </form>
  );
}

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

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

אני מקווה שלמדנו מהעבר, ובכל מקרה העתיד כמו תמיד נשמע מעניין.

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

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

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

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

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

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

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

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

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

def fib(n):
    if n <= 1:
        return 1

    return fib(n-1) + fib(n-2)

הבעיה איתו היא שהוא מחשב את ערכי הביניים יותר מדי פעמים. בניסיון לחשב את fib(10) הוא יחשב את הסכום fib(9)+fib(8), ואז בשביל לחשב את fib(9) הוא שוב יחשב את fib(8). אפשר להיווכח בזה בקלות אם מוסיפים שורת הדפסה בתחילת הפונקציה. הקוד יהיה:

def fib(n):
    print(f"fib({n})")
    if n <= 1:
        return 1

    return fib(n-1) + fib(n-2)

והפלט הוא:

fib(5)
fib(4)
fib(3)
fib(2)
fib(1)
fib(0)
fib(1)
fib(2)
fib(1)
fib(0)
fib(3)
fib(2)
fib(1)
fib(0)
fib(1)
8

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

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

def my_cached(f):
    cache = {}
    def cached_version_of_f(n):
        if n not in cache:
            cache[n] = f(n)
        return cache[n]

    return cached_version_of_f

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

def fib(n):
    print(f"fib({n})")
    if n <= 1:
        return 1

    return fib(n-1) + fib(n-2)


"""
Output:
fib(5)
fib(4)
fib(3)
fib(2)
fib(1)
fib(0)
8
"""

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

better_fib = my_cached(fib)
print(better_fib(5))

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

fib(5)
fib(4)
fib(3)
fib(2)
fib(1)
fib(0)
fib(1)
fib(2)
fib(1)
fib(0)
fib(3)
fib(2)
fib(1)
fib(0)
fib(1)
8

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

fib = my_cached(fib)
print(fib(5))

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

מה קורה כאן? למה אי אפשר לשמור יחד את שתי הגירסאות של הפונקציה?

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

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

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

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

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

try:
    do_something(1)
except Exception as e:
    print("An exception occurred in code block 1:", str(e))

try:
    do_something(2)
except Exception as e:
    # Exception handling code for code block 2
    print("An exception occurred in code block 2:", str(e))

try:
    do_something(3)
except Exception as e:
    print("An exception occurred in code block 3:", str(e))

והשאלה שהתלוותה אליו - האם יש דרך לתפוס את שלושת ה Exceptions באותו try ועדיין להריץ תמיד את כל הפקודות?

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

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

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

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

1. למה הילדים שלי כל כך בלתי נסבלים?

2. למה אף פעם אין לי כסף?

3. למה החיים של כולם יותר מוצלחים משלי?

4. למה לא עשיתי תואר כשהיתה לי הזדמנות?

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

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

2. מה הדרך הכי מהירה לגרום לקוד הזה לעבוד?

3. איך להגיע ל 100% כיסוי בדיקות?

4. אנגולר או ריאקט?

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

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

2. מה הדרך הכי מהירה להבין את הקוד?

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

4. איך לכתוב קוד שיהיה קל לשכתב אותו כשיגיע הרגע, כי Refactor זה משהו שקורה כל הזמן.

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

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

בשביל הדוגמה אני לוקח את בסיס הנתונים Movies מתוך התבנית באתר https://sandbox.neo4j.com. אתר זה מאפשר להקים בסיסי נתונים של neo4j בקלות למשחקים אונליין. בסיס הנתונים של הסרטים כולל מידע על סרטים והאנשים שלקחו בהם חלק, למשל השאילתה:

MATCH (m:Movie) WHERE m.title = 'The Polar Express'
RETURN m.released

תחזיר לי באיזה שנה יצא הסרט The Polar Express, והשאילתה:

MATCH (m:Movie) WHERE m.title = 'The Polar Express'
MATCH (p:Person)-[:ACTED_IN]-(m)
RETURN p.name

תחזיר את שמות השחקנים מהסרט.

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

MATCH (m:Movie)
RETURN m.title
ORDER BY rand()
LIMIT 1

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

MATCH (p:Person{name: "Tom Hanks"})
MATCH (p)-[:ACTED_IN]-(m:Movie)
RETURN m.title

אבל טריק ה rand כבר לא ייתן לי סרט אקראי:

// always returns Apollo 13

MATCH (p:Person{name: "Tom Hanks"})
MATCH (p)-[:ACTED_IN]-(m:Movie)
RETURN m.title
ORDER BY rand()
LIMIT 1

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

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

MATCH (p:Person{name: "Tom Hanks"})
MATCH (p)-[:ACTED_IN]-(m:Movie)
WITH collect(m) as movies
RETURN apoc.coll.randomItem(movies)

סך הכל אפשר למצוא את כל הפונקציות המובנות ב neo4j בתיעוד בקישור: https://neo4j.com/labs/apoc/4.2/overview/, ולקוות לעתיד וורוד ונטול SQL.

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

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

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

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

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

לא משנה מה אתם בונים, חפשו את המעגל: ניסוי, תוצאה, ניתוח ושיפור. ושוב. ושוב. ושוב.

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

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

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

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

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

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

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

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

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