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

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

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

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

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

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

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

יש לכם עוד רעיונות? ספרו בתגובות אשמח לשמוע.

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

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

יש טכנולוגיות חדשות שפשוט מוסיפות יכולות ומפשטות מקרי קצה בעייתיים. אין בעיה לכתוב C++ בלי לדעת כלום על C++11, 14 או 17, אבל מי שכן יודע על הרחבות אלו יוכל לכתוב קוד הרבה יותר מדויק. אין בעיה לכתוב היום JavaScript ES5 אבל מי שיודע גם ES6/7/8 יוכל לכתוב את אותם הדברים בצורה יעילה יותר. ובכל מקרה במצבים כאלה לחדש אין קיום בלי הישן.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ב 2010 רוב עבודות פיתוח אתרים היו ב PHP ו jQuery. רק שנתיים מאוחר יותר מודעות הדרושים בתחום קיבלו תפנית וכולם חיפשו לגייס מפתחי Front End. אם הסתובבתם עם אנשי PHP ו jQuery באותה תקופה אתם וודאי תזכרו את התסכול שלהם. עשר שנים של ניסיון בבניית אתרים הפכו ללא רלוונטיות בזכות התקדמות בפיתוח הדפדפנים. חברות העדיפו לגייס מתכנת JavaScript עם שנה ניסיון באנגולר על פני מתכנת Web מהדור הישן עם חמש-שש שנים ניסיון.

שינויים כאלה זה לא הדבר החריג אלא זה הנורמה. לא משנה על מה אתם עובדים עכשיו סיכוי גבוה שבעוד 5-6 שנים תעשו משהו אחר לגמרי.

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

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

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

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

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

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

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

2. מחפש בגוגל Getting Started ואת שם השפה החדשה וקורא את התוצאה הראשונה שנראית לי רלוונטית.

3. פותר אוסף תרגילים גנריים שלי בשפה החדשה.

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

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

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

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

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

אבל אז מגיעים לחיים עצמם.

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

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

שאלה שחוזרת בקורסים על טכנולוגיה היא ״למה זה טוב?״ או ״במה הטכנולוגיה הזו טובה יותר מהשניה?״. במה Python טובה יותר מ perl ? במה לינוקס טובה יותר מ Windows? במה React טובה יותר מ Angular? ברוב המקרים זאת השאלה הלא נכונה והיא באה מהמקום הלא נכון.

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

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

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

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