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

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

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

״אין טעם ללמוד וים, אני כבר יודע טוב להשתמש ב Webstorm שעובד טוב יותר״

״אין טעם להשקיע ב Redux, אני כבר יודע MobX שעושה הכל טוב יותר״

״אני ממילא עובד רק עם ממשק ה git שמשולב ב IDE שלי, אז אין טעם ללמוד לעבוד איתו משורת הפקודה״

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

״אני כבר יודע Webstorm, אז בטח יהיה מעניין לראות איך עושים פעולה דומה ב vim״

״כתבתי כבר שני פרויקטים ב MobX, אז נראה לי שעכשיו אני מוכן להתמודד עם Redux לפרויקט הבא״

״החודש אני הולך להשתמש ב git משורת הפקודה בלבד - מעניין מה זה ילמד אותי על הכלי שעדיין לא ידעתי״

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

קבלו שאלת ראיונות עבודה זריזה על ריאקט שעלתה בקורס היום - מה ההבדל בין שתי הקומפוננטות האלה, ובאיזה נעדיף להשתמש:

// Component 1
function App() {
  const [value, setValue] = React.useState(_.random(1, 100));

  return (
    <div>
      <button onClick={() => setValue(c => c + 1)}>{value}</button>
    </div>
  );
}

// Component 2
function App() {
  const [value, setValue] = React.useState(() => _.random(1, 100));

  return (
    <div>
      <button onClick={() => setValue(c => c + 1)}>{value}</button>
    </div>
  );
}

נראה ממש דומה לא?

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

ולמה ההבדל חשוב? בגירסת הקומפוננטה הראשונה כל פעם שאנחנו מעלים את הערך באמצעות לחיצה על הכפתור ריאקט יקרא שוב לפונקציית הקומפוננטה כדי לקבל את ה Virtual DOM Tree המעודכן שלה. קריאה כזו תפעיל גם את _.random, תיקח את התוצאה ותעביר אותה ל useState. עכשיו בגלל שהקומפוננטה כבר נוצרה אז useState פשוט יזרוק לפח את הפרמטר שקיבל בגלל שכבר יש לו ערך בסטייט ויוצא שסתם התאמצנו להגריל מספר אקראי.

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

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

המשפט בכותרת הוא תרגום של המשפט הבא מתוך ה Zen של פייתון. זה המקור:

There should be one-- and preferably only one --obvious way to do it.

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

class ShoppingCart < ActiveRecord::Base
  has_many :products, :class_name => 'CartProduct', :dependent => :delete_all

    def <<(product)
        line = CartProduct.find_or_initialize_by(:product => product, :cart => self)
        # comment out to allow quantity
        # line.increment(:qty) unless line.new_record?
        line.save!
        @finalized = false

        self
    rescue ActiveRecord::RecordNotUnique
        retry
    end

    def add_with_options(product, options)
        line = CartProduct.find_or_initialize_by(:product => product, :cart => self)
        line.price = options[:price]
        line.options = options
        line.save!
        @finalized = false

        self
    rescue ActiveRecord::RecordNotUnique
        retry
    end
end

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

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

  test 'cart price is the sum of all product prices' do
    @cart = create(:cart)
    @cart.products << create(:item, price: 20)
    @cart.products << create(:item, price: 50)

    assert_equal(70, @cart.price)
  end

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

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

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

    def <<(product)
        add_with_options(product, {})
    end

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

במקרה שלנו אפשר לחשוב על:

class ShoppingCart < ActiveRecord::Base
    def add_product_sold_by_partner(product, partner_price, partner_options)
    end

    def add_product_from_website(product)
    end
end

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

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

function App() {
  const [text, setText] = React.useState('');

  return (
    <div>
      <input type="number" value={text} onChange={e => setText(e.target.value)} />
      <p>Text: {text}</p>      
    </div>
  );
}

ReactDOM.render(<App />, document.querySelector('main'));

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

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

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

בשביל להבין מה קורה המשכנו לכתוב דוגמא קצת יותר מתוחכמת:

function App() {
  const [numericInputChanges, setNumericInputChanges] = React.useState(0);
  const [textInputChanges, setTextInputChanges] = React.useState(0);
  const [numericInput, setNumericInput] = React.useState('');
  const [textInput, setTextInput] = React.useState('');

  function reset() {
    setTextInput('');
    setNumericInput('');
    setTextInputChanges(0);
    setNumericInputChanges(0);    
  }

  function numericInputChanged(e) {
    setNumericInputChanges(v => v + 1);    
    setNumericInput(e.target.value);
  }

  function textInputChanged(e) {
    setTextInputChanges(v => v + 1);
    setTextInput(e.target.value);
  }

  return (
    <div>
      <p>Numeric Input Changes: {numericInputChanges}</p>
      <p>Text Input Changes: {textInputChanges}</p>      
      <input type="text" value={textInput} onChange={textInputChanged} />
      <input type="number" value={numericInput} onChange={numericInputChanged}  />
      <button type="reset" onClick={reset} >Reset</button>
    </div>
  );
}

ReactDOM.render(<App />, document.querySelector('main'));

וכן, יש גם קודפן:

הפעם אני מציג גם Counter שעולה ב-1 כל פעם שקומפוננטת ה input מפעילה את הפונקציה שכתובה ב onChange. הנה מה שקורה שם:

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

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

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

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

עריכה - ותודה לגדי על התיקון

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

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

אבל שעה כל יום זה ממש אחלה. בשעה כל יום אפשר ללמוד Data Science או Web Development או אפילו גרמנית. שעה כל יום קונה לכם עולם ומלואו.

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

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

מה אתם מחליטים?

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

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

נו, תודה.

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

עכשיו היית מצפה שאחרי כל זה אנשים היו להוטים ללמוד על ה Box Model. נו, תמשיכו לחלום.

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

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

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

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

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

ואז זה לא עובד.

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

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

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

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

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

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

https://unoptimal.files.wordpress.com/2019/11/realgraph.png?w=1424

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

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