ToCode

# תזרים כלל פשוט בעסקים הוא שעדיף לקבל כסף מוקדם ולהוציא כסף מאוחר. בגלל זה כולם אוהבים לשלם בשוטף + שיתייבש ועצמאים תמיד מתלוננים על "מוסר התשלומים הממשלתי". מתחת לכל הקיטורים מסתתרת האמת הפשוטה שגם לכסף יש עלות, וכשהחשבון כל הזמן בפלוס אפשר להשתמש בכסף כדי לגדול. אותו הכלל יכול לעזור לנו להתקדם גם בכתיבת קוד, רק שבמקום כסף יש לנו מוצר ופיצ'רים. כשאני מצליח לעבוד על פיצ'רים שמשתמשים רואים ולתת למשתמשים מוצר מהר אני מקבל כסף יותר מהר. כשאני מצליח לדחות עבודת תשתית ארוכה שלא נותנת לי ערך מיידי אני דוחה את התשלום. בעולם מושלם הייתי קודם נותן ללקוחות את המוצר, ורק אחר כך מתחיל לתכנת אותו. זה כמובן לא אפשרי אבל כן אפשר לבחור באיזה סדר לכתוב פיצ'רים ומנגנונים במערכת. לדוגמה: 1. אני יכול לכתוב בדיקות אחרי שהקוד כבר עובד וכל הממשקים סגורים. הלקוחות שלי יקבלו מוצר יותר מהר ולי יהיה יותר קל לכתוב את הבדיקות. 2. אני יכול לבנות אבסטרקציות מקוד קיים, אחרי שכבר כתבתי את המנגנון ומצאתי קוד משותף בין חלקים במערכת, במקום לתכנן ולכתוב את כל האבסטרקציות מראש. שימוש בקוד קיים יבטיח שהאבסטרקציות שכתבתי נכונות ובאמת יעזרו לפיתוח. 3. אני יכול להעלות את הקוד למערכת כמו Heroku כדי להגיע לאוויר כמה שיותר מהר, ולדחות את כתיבת קוד ה Deployment המסובך לאחרי שהמוצר באוויר. נ.ב. יש הרבה דמיון בין "דחיית תשלומים" ל"חוב טכני", ולכן חשוב להבהיר את ההבדל בין שני הדברים - חוב טכני צובר ריבית והעלות שלו תהיה גבוהה יותר ככל שדוחים אותו יותר. דחיית תשלומים הרבה פעמים מורידה את עלות הפיתוח הכוללת. אז כשאנחנו מדברים על לכתוב בדיקות לסוף אנחנו חוסכים עבודה, כי הממשקים יציבים ויותר קל לכתוב את הבדיקות, ולכן זה מנגנון של תזרים. אבל כשאנחנו נשארים עם גירסאות ישנות של תלויות וממשיכים לבנות עוד קוד על גבי ממשקים ישנים זה כבר חוב טכני, כי ככל שעובר זמן ואני לא משדרג יהיה לי רק יותר קשה לשדרג כשיגיע היום. היו זהירים עם חוב טכני אבל אל תהססו לדחות תשלומים.

# כמה זמן לוקח לכתוב דיאלוג ב CSS? היתרון והחיסרון של Reusable Code הוא שאנחנו כבר לא זוכרים איך לכתוב דברים בסיסיים. והמילה "כבר" פה ממש לא באה לרמוז שזה קטע חדש. - כמה זמן לוקח לכתוב דיאלוג מודאלי בדפדפן? שניה וחצי, רק שורה ב jQuery UI - כמה זמן לוקח לכתוב דיאלוג מודאלי בדפדפן? שניה וחצי, רק שורה ב Bootstrap - כמה זמן לוקח לכתוב דיאלוג מודאלי בדפדפן? שניה וחצי, יש לי ספריית npm שעושה את זה בריאקט אבל חיסכון בעבודה לא שווה הרבה כשהוא בא על חשבון הידע. ועם הקצב שטכנולוגיות מתחלפות זה הרבה פעמים אפילו לא חיסכון בעבודה: לפעמים אני מוצא את עצמי מבזבז זמן על אותה פעולה בסיסית שאני כבר יודע איך לעשות ב 20 שפות אחרות, רק בגלל שהיום כותבים בפריימוורק או שפה חדשים. הפיתרון הוא לשים לב שמתחת לכל הכלים האלה יש שפה אחת, בסיסית יותר, שנקראת CSS. ואם אני יודע לכתוב דיאלוג מודאלי ב CSS אז פתאום אני יכול לבחור - האם ללמוד את הכלי החדש והקסום של היום רק בשביל לקבל עוד עטיפה ל CSS, או להתקדם עם CSS שאני כבר מכיר. לפעמים דווקא מתוך זה שאני יודע כמה מסובך מימוש מסוים אני שמח לקחת פיתרון מדף; אבל הרבה פעמים ברגע שאנחנו מבינים איך לבנות את זה, פיתרונות המדף נראים הרבה פחות אטרקטיביים.

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

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

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

# געגועים ל Higher Order Components לפני Hooks היינו משתמשים בריאקט בתבנית קצת מסורבלת שנקראה Higher Order Components כדי לשתף Stateful Logic בין כמה קומפוננטות, מה שהיום אנחנו עושים בקלות עם Custom Hooks. אבל הרעיון מאחורי Higher Order Components יכול לעזור גם בכתיבת קומפוננטות מודרניות ולאפשר שיתוף קוד טוב ופשוט באפליקציה. ככה זה עובד. ## מה הרעיון של Higher Order Components הרעיון של HoC היה שאם יש לוגיקה שקשורה לסטייט, אפשר להוציא אותה לקומפוננטה נפרדת שעוטפת את הקומפוננטה האמיתית ומעבירה לקומפוננטה האמיתית את הסטייט באמצעות properties. לדוגמה אם יש לנו קומפוננטה שמציגה את מספר השניות שעברו מאז שהוסיפו אותה למסך, וקומפוננטה אחרת שכל שניה משנה תמונה בגלריית תמונות, היינו יכולים לכתוב קומפוננטה גנרית (למעשה זו היתה צריכה להיות פונקציה שמייצרת קומפוננטה) שעוטפת את שתי הקומפוננטות ומוסיפה את הלוגיקה של שעון. ואז בזיכרון של ריאקט הקומפוננטה הראשונה בעצם היתה מופיעה בתור:

<WithClock>
    <ShowTimer time={time} />
</WithClock>

כשהמשתנה time הוא state של הקומפוננטה WithClock, ועובר בתור prop ל ShowTimer שמראה אותו. לגבי הגלריה היינו יכולים לקבל מבנה דומה:

<WithClock>
    <Gallery currentImage={time % images.length} images={images} />
</WithClock>

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

function ShowTimer(props) {
    const time = useClock();
    
    return (
        <p>The time is now ... {time}</p>
    );
}

מה שהופך בזיכרון של ריאקט למבנה של אלמנט יחיד ב Virtual DOM:

<ShowTimer />

אז חסכנו אלמנטים בעמוד והפכנו את הרינדור למהיר יותר, אבל מה הפסדנו בתהליך? ## החסרון של Custom Hook הבעיה עם Custom Hook היא העברת הלוגיקה חזרה לתוך הקומפוננטה כך שקשה יותר להשתמש מחדש בקומפוננטה הפנימית בהקשרים אחרים. בחזרה לדוגמה השעון - יכול להיות שתהיה לי קומפוננטה יותר מתוחכמת שמעבירה את השניות באנימציה וגם מראה שעון מעוצב ויפה. עכשיו במקום אחר באפליקציה אני רוצה להציג את אותו שעון אבל הפעם שיספור אחורה כמה זמן עד שמבצע מסוים נגמר. בגלל שהשעון שלי הוא זה שקורא ל useClock אנחנו בעצם תקועים. ה Hook תמיד מחזיר שעון שסופר קדימה, כי זה מה שהוא מתוכנת לעשות. זאת תהיה נקודה שבה אצטרך לעשות Refactoring ולהוציא את הקריאה ל Hook החוצה כך שאפשר יהיה להשתמש בקומפוננטה גם בלי השעון. ## הצעה לתבנית: לוגיקה ^ אלמנטים דרך אחת למנוע את הבעיה הזאת לפני שהיא קורית חוזרת לרעיון של HoC אבל בצורה הרבה יותר פשוטה - במקום לכתוב קומפוננטה אחת של שעון שגם כוללת קוד תצוגה וגם את הלוגיקה והקריאה ל Hook, אנחנו מראש נפריד את הקומפוננטה, כך שתהיה לנו קומפוננטה אחת שמפעילה את ה hook וקומפוננטה אחרת שמטפלת בתצוגה. בדוגמת השעון זה יהיה:

export default function WithClock(props) {
    const time = useClock();
    return (<ShowTimer time={time} />);
}

function ShowTimer(props) {
    const { time } = props;
    return (<p>The time is now ... {time}</p>);
}

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

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

הי כולם עוד עשר דקות נתחיל וובינר פיצ׳רים חדשים בריאקט 18 מוזמנים להצטרף בקישור: https://us06web.zoom.us/j/88113597884?pwd=bkFZNGJIbmRXZENmSVVKQWZaUHpCQT09

בוקר טוב היום בשעה 10:00 וובינר על פיצ׳רים חדשים ב React 18 לקראת עשר אדביק פה את הקישור לכניסה

# למה סטאק אוברפלו צריכים בדיקות יחידה? בפוסט שעלה עכשיו לבלוג של סטאק אוברפלו הם מספרים על הסיבות שהביאו אותם להתחיל לכתוב בדיקות יחידה. אלה עיקרי הדברים: 1. הם מתבגרים ורוצים לאמץ שיטות עבודה מקצועיות. 2. הם רוצים להיות מסוגלים לעשות Refactoring בקלות בלי לשבור פונקציונאליות ללקוחות קיימים. 3. העבודה עצמה של ארגון הקוד כדי שיהיה מתאים לכתיבת בדיקות מייצרת קוד טוב יותר. 4. קוד עם בדיקות ותיעוד מייצר תחושה של "חוף נקי", שגורם לאנשים אחרים להשאיר אותו נקי לפחות כמו שהיה כשהגיעו אליו. 5. בדיקות טובות מתפקדות כמו תיעוד לקוד. אפשר לקרוא את הבדיקות ולהבין מה כל חלק עושה. 6. את בדיקות היחידה כותבים המתכנתים ולכן קל להם יותר לכתוב בדיקות תוך כדי עבודה על קוד אמיתי. זה בניגוד לבדיקות אוטומטיות רגילות שכותבים אנשי QA או אנשי אוטומציה, ואותן מתכנתים לא מרגישים בנוח לעדכן. בדיקות אוטומטיות שנכתבות בזמן הכתיבה של הקוד וכחלק מהקוד קשורות לאיכות הקוד ולגישה שלנו כשאנחנו כותבים ומתחזקים אותו. האם אני כותב קוד בשביל להוציא משהו מהר ללקוח ומקווה שברובו הוא עובד, או שאני משקיע את הזמן כדי לחקור את מה שכתבתי, לבעוט בו קצת ולראות שהוא מספיק יציב לפני שיוצא מהדלת. כשהדגש הוא על איכות ברור שבטווח הקצר המהירות נפגעת, אבל בטווח הארוך האיכות מאפשרת לקבוצות גדולות לעבוד על מערכות גדולות בלי לשבור דברים.