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

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

1. הספר Social Architecture של פיטר הינצ'נס- פיטר הוא המייסד של חברת iMatix המפתחת מוצר קוד פתוח פופולרי בשם ZeroMQ. בספר הוא מספר על האג'נדה של פיתוח קוד פתוח והמכניקה של איך מגייסים, מובילים ומנהלים צוותי מתנדבים לפיתוח המוצר. אחרי שקראתי את Social Architecture אני מבין הרבה יותר טוב את הדינמיקה וההיגיון של עולם הקוד הפתוח. קישור: https://www.amazon.com/Social-Architecture-Building-line-Communities/dp/1533112452

2. הספר Cryptography Engineering של ניל פרגוסון, ברוס שנייר וטדיושי קונו- ספרים על קריפטוגרפיה הם בדרך כלל משעממים כי הם אוהבים להתמקד בפרטים ופחות בתמונה הגדולה. הספר הזה לא מתקמצן על פרטים אבל לפני שמגיע אליהם הוא עוצר להסביר בצורה מאוד יסודית ומסודרת את התמונה הגדולה ואת ההיגיון של כל פרוטוקול קריפטוגרפי. ספר חובה למתכנתים, אלגוריתמיקאים ובכלל לכל מי שרוצה להבין איך תקשורת מודרנית עובדת. קישור: https://www.amazon.com/Cryptography-Engineering-Principles-Practical-Applications/dp/0470474246

3. הספר Refactoring של מרתין פולרספרים על תכנות נוטים להתיישן מהר מאוד. לא כך הספר Rקכשבאםרןמע שלמרות שכולל דוגמאות קוד Jשהש משנת 1999, עדיין נשאר רלוונטי ביותר גם היום. הספר לימד אותי לחשוב על קוד של מערכות גדולות כדבר נזיל. הוא לימד אותי לא לפחד לשנות קוד תשתית ונתן לי הרבה מאוד כלים לגשת לשינויים כאלה. אגב יש דיבור שבקיץ יוצאת מהדורה חדשה ומעודכנת. קישור: https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672

4. הספר Rails Test Prescriptions של נואל רפין- לימד אותי לכתוב בדיקות יחידה, ונתן לי את הביטחון לכתוב כאלה לפרויקטים שלי. זה הספר הכי טוב על בדיקות שקראתי וקצת חבל שהוא ממוקד ריילס. אם במקרה אתם גם עובדים בריילס שווה מאוד לקרוא אותו. קישור: https://pragprog.com/book/nrtest3/rails-5-test-prescriptions

5. הספר Twenty Four Deadly Sins of Software Security של מייקל הווארד, דייויד לבלנק וג'ון ויגה- הוא ספר מקיף ומדויק עם המון דוגמאות לבעיות אבטחה בתוכנה. הספר לא מנסה להפוך אתכם להאקרים אלא פשוט מציג דוגמאות קוד פגיעות ומסביר לעומק מה הבעיות בהן. יש פה המון דוגמאות מפרויקטים אמיתיים ולכן אם אתם רוצים להבין יותר טוב את העולם של פריצות ולמה מערכות נשברות זה המקום להתחיל בו. קישור: https://www.amazon.com/Deadly-Sins-Software-Security-Programming/dp/0071626751

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

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

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

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

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

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

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

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

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

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

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

// from facebook.com at 2008
// https://web.archive.org/web/20080709203613/http://www.facebook.com/

function show_birthday_help(){
  birthday_popup=new pop_dialog('birthday_warning_popup');
  html='<div class="dialog_body">'
    +tx('sre22')+
    '<br /><br />'+
    tx('sre23')+
    ' <a href="/pages/create.php" title="Create a Page">'+
    tx('sre24')+
    '</a>.'+
    '</div>'+
    '<div id="dialog_buttons" class="dialog_buttons">' +
    '<input type="button" class="inputsubmit" id="dialog_button1" onclick="birthday_popup.hide();" value="'+
    tx('sre26')+'"/></div>';
  birthday_popup.show_prompt(tx('sre25'),html);
}

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

גווידו ון רוסום הוא היוצר של שפת Python. ב 2009 הוא פירסם מניפסט שיוצא כנגד Tail Recursion Elimination. הטענה שלו שזה מעודד הרגלי תכנות גרועים ולכן אסור להכניס יכולת כזו לשפה. ב 2011 חוזה ואלים כתב שפת תכנות בשם Elixir שמתבססת על הרעיון של Tail Recursion Elimination. חוזה טען שרקורסיה ולכן TRE הם המבנים הבסיסיים ביותר בתכנות, שהם עוזרים לייצר קוד קריא ויציב יותר ושלולאות הן האויב (כי לולאות משתמשות ב Mutable Data שהוא הרבה יותר גרוע).

בעולם מקביל, ספריית הקוד הכי פופולרית לבניית אתרים מאז ומעולם נקראת jQuery. שנים ארוכות היא היתה האפשרות הטובה ביותר וכמעט היחידה לפיתוח אתרים. ואז איפשהו ב 2009 לאנשים התחיל להימאס מ jQuery - ב 2010 ג'רמי אשכנז משחרר את Backbone ומישקו הברה את אנגולר: שתי ספריות ששינו ב 180 מעלות את התפיסה של פיתוח Web. בעולם של jQuery התפיסה המקובלת היתה ש JavaScript עובד על מידע ששמור ב DOM. בעולם של Backbone ועוד יותר מזה Angular, קוד JavaScript הוא זה ששמר את המידע וכתב אותו ל DOM כשהיה צריך. לימים React, Vue ו Angular2 המשיכו את הכיוון שטוען שהמידע נשמר ב JavaScript; ולאחרונה DHH שיחרר פריימוורק בשם Stimulus שחוזר לרעיון הישן שהמידע צריך להישמר ב DOM.

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

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

כמובן שלא כל השינויים הם כאלה.

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

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

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

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

הבעיה היא כשהולכים בדרך הלא נכונה.

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

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

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

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

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

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

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

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

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

כמעט בכל המכללות היום מעודדים סטודנטים להשתמש בגיטהאב ולהעלות פתרונות לתרגילים לפרופיל שלהם שם. כן גם אני חוטא בזה בחלק מהקורסים כאן באתר ולראיה יש 190,118 מאגרים בגיטהאב ששמם datasciencecoursera. יש גם מיליון מאגרים בשם hello-world ועוד מיליון שנקראים test. אבל לתרום קוד לפרויקט קוד פתוח זה סיפור אחר לגמרי. לפני כמה חודשים הורדתי את הקוד של gcompris. הבן שלי עף על המשחקים האלה וכל הקוד כתוב ב QML אז חשבתי שיהיה נחמד לכתוב משחק בעצמי. הקוד לא התקמפל בגלל חוסר תאימות למק ב CMakeLists.txt. אני יודע CMake ומהר מאוד תיקנתי את הבעיה, קימפלתי והרצתי. השלב הבא היה לשלוח Pull Request בחזרה ל gcompris עם התיקון כדי שגם אחרים יהנו. בתגובה החברים שם אמרו שאם כבר באתי אולי אני יכול לעזור להם בעוד כמה בעיות שקשורות בתאימות למק ושעדיף להוסיף גם אותן לאותו Pull Request, ושהם גם לא יכולים לקבל ממני PR כי צריכים את השם המלא והחשבון גיטהאב שלי היה בשם ynonp. בסוף אחרי שלושה חודשים התיקון שלי (באורך שתי שורות) כן נכנס לפרויקט הרשמי. לתרום קוד לפרויקט קוד פתוח דורש יכולת לעבוד עם אנשים, להבין את העולם מנקודת המבט שלהם, להיות מוכן להיכנס לדיאלוג ולשפר את העבודה שלך עד שהיא תהיה ברמה מספיק טובה כדי שיקבלו אותה. במקום לעודד אנשים לפתוח עוד ריפוזיטורי בגיטהאב עדיף להתאמץ ולעזור להם לשלוח Pull Request, כל הדרך עד שמתקבל.

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

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

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

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

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

לא, אתם לא צריכים עוד קורס. אתם צריכים להתחיל ללמוד.

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