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

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

וזה הזוי-

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

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

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

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

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

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

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

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

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

ב 2008 דאגלס קרוקפורד פירסם את הספר JavaScript: The Good Parts שטילטל את עולם פיתוח ה Web. באותו ספר קרוקפורד הציע תבניות לעבודה עם JavaScript כדי לבנות בתוך שפת JavaScript את המבנים שמתכנתי Java היו רגילים למצוא בתוכניות שלהם, מבנים כמו מחלקה, ירושה ומשתנים פרטיים.

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

קטע הקוד הזה הוא דוגמא מתוך הספר שמשקף את הסגנון של קרוקפורד ושל הקוד שהיה מקובל באותה תקופה:

var Mammal = function (name) {
  this.name = name;
};

Mammal.prototype.get_name = function (  ) {
  return this.name;
};

Mammal.prototype.says = function (  ) {
  return this.saying || '';
};

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

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

קוד Angular שמתכנת ווב יכתוב היום יהיה כתוב בסגנון הזה:

import { Component } from "@angular/core";

@Component({
  selector: "app-root",
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"]
})
export class AppComponent {
  title = "CodeSandbox";
}

שבכלל כתוב ב TypeScript.

ב Vue קוד טיפוסי משתמש באוביקט פשוט:

import { reactive, computed } from 'vue';

export default {
  setup() {
    const state = reactive({
      count: 0,
      double: computed(() => state.count * 2)
    });
    function increment() {
      state.count++;
    }
    return { state, increment };
  }
};

ובריאקט הבסיס לרוב הקומפוננטות הוא הפונקציה:

export default function App() {
  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <h2>Start editing to see some magic happen!</h2>
    </div>
  );
}

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

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

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

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

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

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

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

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

Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אבל קורס יכול (וצריך) להיות הזדמנות:

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

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

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

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

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

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

רישום לקורס פייתון במסלול בוטקמפ בפיג'מה

רישום לקורס ריאקט במסלול בוטקמפ בפיג'מה

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

בקיצור הכלי החדש האהוב עליי בימים אלה נקרא nano-react-app והוא תחליף ממש פשוט ל create-react-app (קיבל כבר מעל 300 כוכבים בגיטהאב). וזה מצחיק כי הוא באמת לא עושה כלום - כלומר הוא עושה קצת. הוא לוקח טמפלייט מהאינטרנט ליישום ריאקט JavaScript או TypeScript, משנה קצת את התוכן בקבצים וזה בערך כל הסיפור.

בניגוד ל create-react-app הוא לא מבטיח לכם פרויקט עם כל התוספים וכל הספריות מחוברות במקום אלא בדיוק להיפך. אתם תקבלו קומפוננטה קטנה (ב JavaScript או ב TypeScript) ותמשיכו לבד. בדיקות? הצחקתם אותו. סרביס וורקר? למי יש כח לזה. טמפלייטס מורכבים עם Redux או MobX? עזבו, תכתבו לבד.

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

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

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