ToCode

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

# צעדים קטנים זה נחמד - אבל מה הצעדים? העצה הקלאסית של לימודים אומרת שכדאי להתקדם בצעדים קטנים: לדוגמא קודם תלמדי לנסוע על אופני דחיפה, אחרי זה תעברי לגלגלי עזר ובסוף אופניים רגילים. וזה יפה בתיאוריה אבל השטן הוא בפרטים: איזה צעדים צריך לקחת בשביל ללמוד את הדבר הזה שאני רוצה ללמוד? (בדוגמת האופניים, אולי גלגלי העזר באמצע רק מאטים את הלימוד). באחד הקורסים הפחות טובים שלימדתי קהל היעד היה אנשים ללא רקע בתכנות והסילבוס התחיל עם עולם ה 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. וזה נכון, כי פרילאנסרים עובדים בסולם אחר לגמרי מזה של מתכנתים בחברות גדולות ובמערכת אילוצים אחרת לגמרי. בחירת הצעדים והסולם שיתאימו למקום אליו אתם רוצים להגיע היא החלק הכי חשוב בתהליך הלימוד, ולצערי זה החלק שהרבה אנשים מדלגים עליו או משאירים אותו ליד המקרה. החלק הכי קשה בבניית קורס הוא לא ההסבר עצמו, אלא הבחירה מה ללמד ובאיזה סדר.

# צ'קליסט לבדיקת פרויקט ריילס לאחרונה אני מסתובב הרבה באפוורק כדי למצוא פרילאנסר/ית לפרויקט ריילס וככה יוצא לחטט בהרבה מאגרי גיטהאב של אנשים. בשביל לא להתחיל כל פעם לחשוב מחדש מה צריך להיות בפרויקט הכנתי צ'קליסט קטן של דברים שאני מחפש לפי סדרי עדיפויות. מוזמנים לקרוא לספר מה דעתכם וגם להציע סעיפים שפספסתי. ## אבטחת מידע הרגלי אבטחת מידע זה משהו שקשה מאוד ללמוד ועל טעויות אבטחת מידע קשה מאוד לעלות ב Code Review שוטף. הבעיה שפשוט אנשים כותבים יותר מדי קוד ובנושא אבטחת מידע כל פסיק לא במקום יכול להיות קטלני, ולכן אני מעדיף לסנן מראש מתכנתים שלא מודעים לנושא או שאין להם את האינסטינקט של קוד מאובטח. זה לא אומר שאנחנו נתפוס 100% מהבעיות - תמיד יהיו בעיות. אבל כן חשוב שנקודת ההתחלה תהיה של כתיבה מאובטחת. בפועל בפרויקט ריילס זה מתרגם ל: 1. לשים לב לנקות כל פרמטר שמגיע מה Client. 2. לוודא בקרת גישה נכונה לכל נתיב. 3. לוודא ניקוי יסודי של קלט לפני פקודות פגיעות במיוחד (כמו system או eval). 4. לוודא שכל המחרוזות שנכנסות ל HTML עברו ניקוי. אם הפרויקט נראה רציני אפעיל עליו גם את brakeman כדי לראות שלא פספסתי כלום, אבל בדרך כלל את הדברים הגדולים אפשר לראות בעין. ## התמודדות עם הבלתי צפוי התכונה השניה שאני מחפש אצל מתכנים היא הבחירה להתמודד גם עם מצבים מפתיעים בקוד. בפרויקט ריילס זה אומר למשל תמיד לבדוק שהשורה שניסית להכניס ל DB באמת נשמרה ולכתוב קוד שיודע להיכשל יפה אם היתה בעיה. נקודות בגדול שחשוב לשים לב אליהן יהיו: 1. לוודא שתמיד אחרי save או create יש בדיקה של ערך ההחזר. 2. לוודא שמוגדר Exception Handler גלובאלי ליישום כדי שמשתמשים לא יקבלו מסך "שגיאת שרת". 3. לדאוג ל Validation על מידע גם במודלים וגם לאינדקסים בבסיס הנתונים. 4. לדאוג לערכי ברירת מחדל במודלים ובבסיס הנתונים. ## ביצועים בעיה נוספת אופיינית ליישומי Rails היא שימוש לא נכון ב ORM שגורם לבעיות ביצועים. בעולם מושלם אנחנו רוצים שמספר הפניות לבסיס הנתונים מכל דף יהיה חסום ועדיף שיהיה קבוע. בחיים האמיתיים קורה שיש מספר משתנה של שאילתות, אבל אם מספר השאילתות יכול לגדול עד אין סוף אנחנו בבעיה. בעיה של שאילתות לא חסומות מופיעה כמעט תמיד בתיקיית ה views בתוך קבצי ERB כשקוד ERB מבצע שאילתות בתוך לולאה. דוגמא לקוד ריילס בעייתי כזה היא:

<table>
<tr>
    <th>User Name</th>
    <th>Tasks Count</th>
</tr>
<% @users.each do |user| %>
<tr>
    <td><%= user.name %></td>
    <td><%= user.tasks.count %></td>
</tr>

עבור כל משתמש מתוך @users אנחנו שולפים מבסיס הנתונים את מספר כל המשימות של אותו משתמש. ככל שיהיו יותר משתמשים כך יהיו יותר שליפות וכך העמוד ייטען הרבה יותר לאט. תקלה כזאת מאוד אופיינית ליישומי ריילס ויש אפילו ספריה שעוזרת למצוא קוד עם הבעיה, אבל כשמסתכלים על פרויקט דוגמא הרבה פעמים גם בעין קל לראות את זה. ## בדיקות ותיעוד סעיף אחרון שאני בודק הוא איכות הבדיקות והתיעוד. אם פרויקט הדוגמא שהפרילאנסרית בחרה לשלוח כולל את קובץ ה Readme הדיפולטי של ריילס זה חשוד. אם אין בדיקות זה Deal Breaker אבל גם בהנחה שיש בדיקות בהרבה פרויקטים הבדיקות פשוט לא בודקות כלום. לדוגמא בפרויקט של ניהול משימות אתה יכול למצוא בדיקה שנראית כך: 1. כנס לטופס "יצירת משימה חדשה" 2. הכנס את פרטי המשימה בטופס 3. וודא שעל המסך הופיע הטקסט "המשימה נוצרה בהצלחה" זו בדיקה גרועה כי המטרה של הטופס היא ליצור משימה חדשה, ולכן היינו מצפים שבדיקת הטופס תסתיים בוידוא בבסיס הנתונים שאכן המשימה החדשה נוצרה. בדיקות גרועות בפרויקט זה לא סוף העולם כי זה משהו שאפשר יחסית בקלות לשפר, אבל בדיקות טובות בפרויקט בהחלט יכולות להוסיף הרבה נקודות ולשפר את הרושם. זו הרשימה שלי - אם יש לכם הצעות או דברים אחרים שאתם הייתם מסתכלים עליהם בפרויקטי דוגמא מוזמנים לספר בתגובות.

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

# לא צריך קורס אני עדיין זוכר את עצמי בתור ילד יושב בשיעור וכותב את כל מה שהמורה אומרת. הפה של המורה היה המקור היחיד לקבל ידע: בלי אינטרנט, ועם ספרי לימוד לא מדויקים, השאלה "מה נכון" היתה זהה לשאלה "מה אמרה המורה בשיעור". אני לא חושב שאפשר היום לדמיין אפילו מצב כזה, ובמיוחד בתחום שלנו. בכל הרצאה שהעברתי ולכל קהל - לכל בן אדם בקהל היתה גישה בדיוק לאותם מקורות מידע כמו לי. כל בן אדם בקהל יכל לבדוק כל מילה שאני אומר וכל משתתפת עירנית יכלה לזהות ברגע את הטעות הכי קטנה שלי. בתוך זה הרבה אנשים שואלים את עצמם "מי בכלל צריך את זה?", "למה אנחנו עדיין צריכים קורסים?" ואפילו "עזוב אותך קורסים. מתכנתים טובים לומדים לבד מהאינטרנט". הרי, אם יש לי גישה לאותם מקורות מידע מהם המרצה למד, אז למה אני צריכה את התיווך הזה? לא יהיה יותר קל ומדויק ללמוד ישר מהמקור? אבל - אם אין תעודה, ואם אין ידע סודי, ואפילו אין חוויה כיפית במיוחד (כי, בואו, רוב ההרצאות שהייתי בהן היו די משעממות), אז אולי בכלל לא צריך קורסים יותר? לפחות בתחום שלנו של תכנות אני חושב שהרבה יותר מועיל להסתכל על הקורס בתור "הזדמנות" מאשר בתור "צורך". את לא צריכה קורס בשביל ללמוד את החומר. אם את אוהבת הסבר של מורה מסוים עדיף לצפות בוידאו. או אם את מעדיפה אפשר גם ללמוד מספר, מתיעוד, מכל מרצה אחר בעולם או אפילו מקריאת קוד המקור עצמו. אבל קורס יכול (וצריך) להיות הזדמנות: 1. הזדמנות לכתוב קוד יחד עם אנשי מקצוע כמוך, ולקבל רעיונות שלא חשבת עליהם לבד. 2. הזדמנות לקרוא קוד של אחרים ולקבל מהם רעיונות שתוכלי ליישם אחר כך על המערכת שלך. 3. הזדמנות לראות בזמן אמת איך אנשים אחרים מתמודדים עם אתגרים, ואיך נראה תהליך פיתוח של מתכנתים במקומות אחרים. 4. הזדמנות לחבר בינך לבין מתכנתים שעובדים באותה שפת תכנות אבל על מוצרים אחרים ובמקומות אחרים. 5. הזדמנות לנסות טכנולוגיה חדשה, לטעות ולתקן בסביבה בטוחה לפני שמגיעים לבנות מערכת אמיתית. את כל ההזדמנויות האלה אתם תקבלו במסלולי הבוטקמפ החדשים פה בטוקוד. אתם לא צריכים את הקורס הזה - אבל אם אתם מתכנתים טובים, אתם בטוח רוצים אותם. מתחילים עוד שבוע וחצי (הקבוצה של פייתון כבר כמעט מלאה אז אם אתם מתלבטים עדיף שתירשמו לריאקט שיהיה לי מאוזן): רישום לקורס פייתון במסלול בוטקמפ בפיג'מה רישום לקורס ריאקט במסלול בוטקמפ בפיג'מה

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

# ארבעה טיפים להעברת ביקורת יעילה יותר ב Code Review הבא שלכם הנזק של ביקורת גרועה יכול להיות גדול בהרבה מהתועלת שלה - במיוחד כשמדברים על קוד. יש עדיין קבוצות של קוד פתוח שבהן מתכנתים חדשים צפויים לקבל מבול של העלבות על כל שורת קוד לא במקום, אבל האמת שזה הולך ומתמעט ואפילו לינוס טורוולדס כבר מתחיל להיות נחמד. אבל הסכנה עדיין קיימת גם בחוץ וגם במקומות עבודה מסוימים. בואו ננסה להתמקד רגע ולראות איזה מאפיינים יש לביקורת גרועה ואיך אנחנו יכולים להעביר ביקורת יעילה יותר ב Code Review הבא שלנו: ## העבירו ביקורת על הקוד - לא על המתכנת הטעות הכי גדולה שאנשים עושים ב Code Reviews ושיכולה להרוס את כל הקסם היא להעביר ביקורת (אפילו מרומזת) על הבן אדם שכתב את הקוד במקום על הקוד עצמו. ב Code Review אין מקום להערות כמו "איפה למדת לכתוב ככה?", "את טרחת בכלל לבדוק את הקוד לפני הקומיט?" ואפילו לוותר על ה"ממך לא הייתי מצפה לטעות כזאת". כשיושבים עם חבר או חברה ל Code Review חשוב לעשות מאמץ לשכוח מי הבן אדם שכתב את הקוד ולהתמקד בקוד עצמו ובדברים הטובים והגרועים שבו. ככל שנישאר יותר ממוקדים כך יש יותר סיכוי שהמתכנת שמקבל את הביקורת ימשיך להקשיב ולהשתפר. ## שני "כן" על כל "לא" טיפ טוב תמיד ובמיוחד כשקוראים קוד. הרעיון להתמקד במה שאפשר כן לעשות ואיך אפשר לתקן את הבעיות במקום בבעיות עצמן ובכמה הן חמורות. לכן במקום להגיד "לשאילתה הזאת לוקח יותר מדי זמן לרוץ" עדיף ללכת על "אני רואה שה Migration כאן לא יוצרת אינדקסים על כל העמודות שרלוונטיות לשליפות. שווה תמיד לפני כתיבת Migration לעשות רשימה של כל העמודות שחשובות לשליפות כדי שנדע איפה לשים את האינדקסים. בוא נראה איך עשינו את זה בטבלאות אחרות במערכת". בצורה כזאת אנחנו נותנים לבן אדם את הכלים להבין על מה ליצור אינדקסים וכן איך להסתכל על קוד ישן טוב וללמוד ממנו. או במקום להגיד "מי כותב eval בצד השרת!? איפה למדת לכתוב קוד???" נעדיף להגיב במתינות "אני רואה שבחרת להשתמש ב eval כדי לפענח את ה JSON שהגיע מה JavaScript. שימוש כזה ב eval הוא בעיית אבטחה רצינית. אצלנו במערכת מפענחים JSON-ים עם JSON.parse. ואגב יהיה יותר קל להעביר את הפרמטרים האלה בתור רשימה פשוטה במקום בתור JSON". וככל שאתם מצליחים להציע יותר רעיונות לשיפור על כל בעיה שמצאתם כך עזרתם למתכנת שאיתכם לראות דרכים נוספות לפתור את אותה בעיה ונתתם לו כלים להצליח בפעם הבאה. ## היכנסו לראש של מי שכתב את הקוד אחד החלקים הכי קשים ב Code Review הוא להיכנס לראש של מי שכתב את הקוד ולהבין את האילוצים, את הרצונות ואת ההרגלים שלהם לפני שבכלל אתם מעלים את ההערה הראשונה. אני אוהב להתחיל Code Review בקריאה כללית של כל הקוד ואם הבן אדם שכתב את הקוד לידי אז בהתחלה אני שואל המון המון שאלות כדי להבין מאיפה כל דבר הגיע. כשמתכנת לא זכר למחוק קטע קוד או הערה שנוצר אוטומטית מאיזה Generator זה הרבה פחות גרוע מאשר אם המתכנת כתב לבד קטע קוד מיותר שאף אחד לא קורא לו. ## הציעו דרך פעולה ברורה לשיפור בהמשך במהלך ה Code Review חשוב להבין איזה פערי ידע גרמו לכתיבת הקוד עם הטעויות. בצורה כזאת נוכל להציע בסוף ה Review דרך עבודה ברורה וספציפית לשיפור פערי ידע אלה. לדוגמא אם עברתי על קוד JavaScript שמשתמש ב var, אוכל לברר האם המתכנת שכתב את הקוד יודע את ההבדל בין var, let ו const ואם לא אוכל להציע לו מדריך טוב על ההבדל ביניהם כדי להשתפר לפעם הבאה. ככל שאנחנו יודעים להפנות את המתכנתים שאיתנו למשאבי לימוד טובים ומדויקים יותר שמתאימים לבעיות ולפערי הידע שלהם, כך עזרנו להם להשתפר ולהיות מתכנתים טובים יותר לקראת ה Code Review הבא.

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

const email = {
    bob: 'bob@gmail.com',
    jane: 'jane@gmail.com',
    dave: 'dave@hotmail.com',
};

אז נוכל להשתמש בלולאת for...in כדי להדפיס את כל האנשים שיש להם כתובת מייל בג'ימייל:

for (let name in email) {
    const address = email[name];
    if (address.endsWith('@gmail.com')) {
        console.log(name);
    }
}

אבל - לולאת for...in כוללת גם מוקש קטן. המפתחות שחוזרים הם לא רק המפתחות מהאוביקט שאתם סורקים, אלא גם המפתחות מכל ה Prototypes של אותו אוביקט. לכן הקוד הבא ידפיס 3:

let count = 0;
const one = { a: 10, b: 20 };
const two = Object.create(one);
two.c = 30;

for (let k in two) {
    // count the keys
    count ++;
}

console.log(count);

הלולאה ספרה שני מפתחות מהאוביקט one ועוד מפתח אחד מהאוביקט two וכך הגיעה ל-3. כשיש לנו אוביקט ביד לא תמיד אנחנו יודעים לצפות מי ה Prototype שלו ואיזה מאפיינים הגיעו מאותו Prototype, ולכן לולאות for...in עלולות לרוץ על יותר מפתחות ממה שציפינו. בקוד JavaScript חדש אנחנו מעדיפים להשתמש בפונקציה Object.keys שמחזירה רק את המפתחות של האוביקט שהעברתם לה. קוד מקביל עם Object.keys יראה כך והפעם ידפיס 1:

let count = 0;
const one = { a: 10, b: 20 };
const two = Object.create(one);
two.c = 30;

for (let k of Object.keys(two)) {
    // count the keys
    count ++;
}

console.log(count);

# סיגנלים כשאנחנו מחפשים לגייס מתכנתת חדשה לצוות הרבה פעמים מספר המועמדים גדול בהרבה מכמות האנשים שאנחנו צריכים - או במילים אחרות על כל אחת שתפסול יגיעו 3 מועמדות נוספות. בסיטואציה של ראיון עבודה מאוד קשה להתרשם מכל היכולת האינטלקטואלית של המועמד ולכן הרבה מאוד פעמים חלק מהראיון הוא שלב "המסננת". בשלב זה אנחנו עשויים להציג למרואין שאלה מקצועית מתוך מטרה לעורר דיון, ואז נחפש בתשובות סיגנלים שאומרים שהמתכנת הזה לא מתאים לנו. במשחק הזה לכל מראיין ומראיינת יש סיגנלים אחרים שהם מחפשים ולכן חשוב מאוד להכיר את הסיגנלים הרעים ולנקות אותם מהמערכת שלנו כדי שלא נזרוק הערה טיפשית בטעות. ובגלל שאני אוהב לדבר בגובה העיניים בואו נראה מספר דוגמאות מתחום פיתוח Web לסיגנלים שעשויים לפסול אתכם מהתפקיד הבא: 1. שימוש במנגנונים ישנים וגרועים של JavaScript - נכון, כנראה יהיו מקומות שיפסלו אתכם כי כתבתם var במקום const בתרגיל הבית, אבל הרבה יותר סביר להיפסל על מנגנונים גרועים באמת. שימוש ב eval במקום ב JSON.parse למשל יהיה דגל אדום לרוב מתכנתי ה Front שאני מכיר. אותו דבר לגבי with או onclick בתור מאפיין של תגית HTML. 2. בעיות אבטחת מידע - עדכון innerHTML מתוך קלט לא מסונן שהגיע מהשרת זה דגל אדום לכל מי שאי פעם נכווה מתקלת XSS. 3. ביצועי JavaScript זה לא משהו שהרבה אנשים מתרגשים ממנו, אלא אם כן ממש תעשו שטויות. לרוץ בלולאה על כל האלמנטים בעמוד במקום להשתמש ב querySelector ממוקד יותר למשל ירים הרבה גבות ואותו דבר לגבי הגדרה של יותר מדי Event Handler במקום להשתמש ב Delegation. לצערי גם כשאנחנו יודעים בראש איך צריך להתנהג, הרבה פעמים בסיטואציה מלחיצה של ראיון עבודה או בכתיבת קוד אמיתי בלחץ של לוחות זמנים אנחנו שוכחים ומתעלמים מקוד גרוע שאנחנו כותבים. הדרך להיפטר מהרגלים רעים היא קודם כל לשים לב אליהם, אחרי זה לנקות אותם מהקוד שלנו ואז להמשיך ולחזור על הפעולה שוב ושוב במסגרת אימון. דווקא כשאנחנו סלחנים כלפי עצמנו (נו, זה רק תרגיל... עזוב זה רק בגלל הלחץ של הראיון, בחיים האמיתיים אני לא ככה וכו') אנחנו מעודדים את ההרגל ומחזקים את התודעה שתכנות נכון הוא משהו שצריך להתאמץ בשבילו. ודחיפה קטנה לסיום- הרבה אנשים חושבים שבקורס צריך רק ללמוד טכנולוגיה חדשה. אבל האמת שקורס הוא המקום המושלם לא רק ללמוד איך צריך לעשות אלא גם לתרגל ולאמן את שרירי ה Best Practice כדי שהאינטואיציה הראשונה שלנו תהיה לפתור את הבעיות בצורה הנכונה. זאת החשיבות של תרגול ו Code Review כחלק מתהליך הלימוד. בעוד כשבועיים אני הולך לפתוח שני קורסים ראשונים שהולכים לשים את התרגול והאימון במרכז ויעזרו לכם גם ללמוד את הטכנולוגיה וגם לפתח הרגלי עבודה נכונים שישארו אתכם למשך שנים. פרטים על המסלולים בקישורים- קורס Python במסלול בוטקמפ בפיג'מה. קורס React במסלול בוטקמפ בפיג'מה.