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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. מה בדיוק לא עובד להם?

2. החל מאיזו גירסה של הקוד הדבר שהם מנסים לא עבד?

3. האם יש הודעת שגיאה באחד הלוגים?

4. האם משהו (חוץ מהקוד) השתנה על השרת?

5. מה הלקוח רואה אצלו על המכונה?

6. האם יש הודעות שגיאה ב Browser Console אצל הלקוח?

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

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

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

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

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

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

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

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

1. לשים לב שיש בעיה.

2. למצוא מלא פיתרונות שלא עובדים.

3. למצוא פיתרון שעובד.

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

5. להסביר את מה שגיליתם לאדם אחר (או לכתוב לעצמכם).

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

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

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

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

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

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

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

2. לקוח שמחזיק מערכת CI שמריצה את כל הבדיקות כל לילה יריץ בדיקות הרבה יותר בקלות בהשוואה לחברה בה המתכנתים מריצים לעצמם את הבדיקות על המכונות שלהם כשיש להם זמן. בפעם הראשונה שבדיקות נכשלות למשל בגלל שה Chrome Driver מתיישן אנחנו מיד רואים את זה ויכולים לתקן (לעומת מישהו שמריץ בדיקות פעם בכמה שבועות ואז כל הרצה של הבדיקות מחזירה אינסוף כישלונות ואף אחד לא זוכר אם זה אי פעם עבד).

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

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