טיפים קצרים וחדשות למתכנתים
הבנאי new Array עם פרמטר מספרי תמיד מצליח להפתיע, מאחר והוא מייצר מערך שלא הייתם יכולים להגיע אליו עם אופרטור הסוגריים המרובעים. בואו נדבר על ציפיות, הדפסות ואיך מתמודדים.
תחום פיתוח Front End הוא היום אחד החמים בתעשיה והדרישה לעובדים בשמים. יחד עם זאת, מתכנתים רבים שנכנסים לתחום מתוך תקוה למצוא עבודה חדשה מגלים שהחיפוש קשה ולמרות המחסור המגייסים בררנים.
אנסה להסביר כאן את המניעים לבררנות, ולתת טיפים איך להתבלט וכן להשתלב בעבודה.
יש בעיה עם דוגמאות Hello World כשמדברים על ספריות קוד- הן פשוטות מדי ולא מצליחות להציג את היתרונות של ספריות מורכבות. ריאקט למשל כמעט תמיד תראה מסובכת יותר מ jQuery בדוגמאות פשוטות. לשמחתנו מדי פעם עולה דוגמא קצת פחות פשוטה אבל שעדיין נכנסת ב 50 שורות קוד שמראה את היתרונות.
בעוד שאת התחביר של JavaScript יחסית קל ללמוד, פיתוח ארכיטקטורה ליישומי צד-לקוח היא משימה יותר מורכבת. הסביבה אינה מגדירה ארכיטקטורה סטנדרטית ל״אפליקציית ווב״ (ובכלל, מהי אפליקציית ווב), והפיתוחים ביכולות הדפדפנים ובשפה עצמה יצרו דרכים שונות לכתוב קוד צד-לקוח לאורך השנים.
אני חושב שזו אחת הסיבות לפופולריות של Frameworks ולחיפוש אחר ספריה אחת שתתן תשובה לכל השאלות. החיפוש אחר הדרך הנכונה לפתור בעיה ב Angular, React, Redux או Durandal הוא בעצם חיפוש אחר ארכיטקטורה לאפליקציה שלנו. לכן ולפני שמתחילים לכתוב יישום צד-לקוח גדול, כדאי להתעמק קצת יותר ברעיונות ובארכיטקטורה שאותן Frameworks מתבססות עליה.
הודעה מתלמיד שלא הצליח לאפס סיסמא שלחה אותי למסע בעקבות המייל המושלם, עם כמה לקחים חשובים. האמ;לק של הסיפור הוא לא לשלוח הודעות אוטומטיות דרך שרת מייל שלא מיועד ספציפית לכך. הסיפור המלא בהמשך הפוסט.
בפעם הראשונה שניגשתי לכתוב בדיקות יחידה לפרויקט אפילו לא ידעתי איפה להתחיל. הקוד כולו, שהשקעתי ימים בבנייתו עם ארכיטקטורת Object Oriented ובצורה מודולרית, נראה פתאום כמו כדור בוץ ענק שמזמן התקשה. מאז הספקתי לכתוב ולמחוק שני סטים של בדיקות (כמה מאות בכל סט) וכעת אני בנסיון השלישי, שלשם שינוי נראה טוב.
אלה חלק מהטעויות שעשיתי בתהליך, בתקווה שיעזרו גם לכם לכתוב בדיקות טובות יותר.
הפופולריות והפשטות של שפת JavaScript יצרו מצב מטריד למגייסים: המון משאבי למידה חינמיים ברשת מאפשרים ללמוד JavaScript בן לילה, וכולם צריכים לגייס מתכנתי JavaScript. התוצאה היא הרבה יותר מדי קורות חיים עם המילה JavaScript, שלא מעידה על מיומנות אמיתית בשפה.
האשמה כמובן לא בלומדים. כשלומדים לבד קל להפריז ביכולות או בהבנה שלך. אז בשביל המגייסים והמתגייסים לתפקידי פיתוח Web, אני רוצה להציע אוסף שאלות שכל שועל JavaScript צריך לדעת לענות עליהן. אם אתם לא בטוחים לגבי חלק מהתשובות, או אם המועמד שמולכם מגמגם כשאתם מעלים אחת מהן אולי הגיע הזמן לחזור לספרי הלימוד.
יותר מדי חברים שלי שהם פרילאנסרים או בעלי עסק המבוסס על תוכנה מחזיקים את הקוד שלהם בארון: על המחשב, מסונכרן ב Dropbox, על שרת שלהם או במיליון מקומות לא מתאימים אחרים.
בעולם התוכנה הדרך הטובה ביותר לשמור על קוד היא במערכת ניהול גרסאות ייעודית, והכי נוחה לשימוש היום היא המערכת שמציע Github.
בעבר מתכנתים רבים השתמשו במאפיינים מסוג onClick על הכפתורים כדי לחבר קוד לאירועים. לימים, המעבר לפיתוח מונחה עצמים די ביטל אפשרות זו, מאחר והפונקציות כבר לא היו זמינות באופן גלובלי (אלא רק כשדות של אוביקטים).
אבל קשירת אירועים מתוך HTML עדיין נראית כרעיון טוב במצבים מסוימים. זה נוח שהכל נמצא במקום אחד (לראיה הפופולריות של ריאקט). בפוסט זה נבנה מנגנון bindings פשוט בעצמנו ואני מקוה שזה יעזור לכם להבין איך מנגנונים כאלה בנויים.
לאחרונה רוב קוד התקשורת שאני כותב לא משתמש ב jQuery אלא ישירות ב XMLHttpRequest. התמיכה בדפדפנים טובה, יש את כל היכולות והממשק מאוד נוח. רק מה, יש מספר כותרות שצריך לזכור להוסיף לבקשות כדי שספריות צד השרת שלכם ידעו למה אתם מתכוונים כשאתם שולחים הודעה, כותרות ש jQuery מוסיף באופן אוטומטי לכל הודעה.