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

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

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

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

$ rvm list

   ruby-2.0.0-p247 [ x86_64 ]
   ruby-2.1.2 [ x86_64 ]
   ruby-2.3.1 [ x86_64 ]
 * ruby-2.4.4 [ x86_64 ]
   ruby-2.5.0 [ x86_64 ]
=> ruby-2.6.3 [ x86_64 ]

# => - current
# =* - current && default
#  * - default

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

$ rvm use 2.1.2

ונוודא שאכן הגירסא הוחלפה עם:

$ ruby --version
ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin13.0]

אז איפה הטריק? מסתבר שאם נשים בתוך תיקיה קובץ בשם .ruby-version, באופן אוטומטי בכניסה לתיקיה גירסת הרובי תשתנה כדי להתאים לקובץ זה. זה נראה ככה:

$ mkdir test
$ cd test
$ echo ruby-2.1.2 > .ruby-version
$ cd ..
$ ruby --version
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18]

$ cd test
$ ruby --version
ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin13.0]

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

$ type cd
cd is a function
cd () 
{ 
    __zsh_like_cd cd "$@"
}

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

cd()
{
    echo "wow"
    cd "$@"
}

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

cd()
{
    echo "wow"
    builtin cd "$@"
}

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

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

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

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

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

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

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

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

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

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

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

פוסט אורח מאת ערן גולדמן-מלכא

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

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

כל אחד בוחר את המטרות שלו ואת ההקרבה שהוא מוכן כדי להגיע עליהן.

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

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

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

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

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

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

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

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

1. לדבר עם אנשים אחרים שהתמודדו עם בעיות דומות ולשמוע מה הם עשו.

2. ללמוד יותר על עולם התוכן הרלוונטי (קורס מקוון, ספר, קריאת תיעוד).

3. להמשיך לפתור בעיות אחרות ולחזור לזה עוד חודשיים-שלושה כשאהיה יותר משופשף.

4. לכתוב פיתרון שאני יודע שהוא לא מושלם רק בשביל שאפשר יהיה להתקדם (ואחרי זה לחזור לתקן).

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

חבר סיפר לי השבוע שהם מתלבטים בין Vue ל React לפרויקט הבא. בשיחה אחרת חברה שאלה באיזה כלי CI כדאי להשתמש וחבר שלישי לא הצליח להחליט אם לפתח את האפליקציית מובייל שלהם ב React Native או ב Flutter.

ובתכל'ס כולם מודאגים מאותם הדברים-

1. מה אם אבחר את הכלי הלא נכון?
2. מה אם בעוד חצי שנה לא אצליח לבנות איזה פיצ'ר בגלל הכלי שבחרתי?
3. מה אם הכלי שבחרתי יעלם מהשוק בעוד שנה?
4. מה אם לא אצליח להגיע לביצועים שאני רוצה?

או במילים אחרות: "מה כדאי לבחור כדי שלא אתחרט על זה בהמשך?"

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

אני רוצה להציע רעיון אחר - במקום לשבור את הראש כדי לנסות למצוא את הכלי הכי טוב עבורכם, נסו לסנן החוצה את כל הכלים שלגמרי לא באים בחשבון ולבחור באקראי את אחד מהנשארים. בינינו, יש סיכוי טוב שגם ב React וגם ב Vue תצליחו לבנות יופי של אפליקציה; שגם ב Jenkins, גם ב Travis וגם ב Circle CI תוכלו לבנות יופי של אינטגרציה ואפליקציית המובייל שלכם תרוץ גם אם תכתבו אותה ב RN, גם ב Flutter ואפילו אם תלכו על Xamarin. עדיף לכתוב קוד מאשר לבזבז את הזמן בהתלבטויות.

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

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

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

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

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

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

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

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

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

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

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

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

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