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

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

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

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

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

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

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

ובכל זאת לגבי רמיני - ההשוואה לפייסבוק מטעה. בפייסבוק סגרו את הפירצה במערכות ה 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 בגלל השם המצחיק.

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

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

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

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

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

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

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

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

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

מקווה שתהנו. ינון.