טיפים קצרים וחדשות למתכנתים
לאחרונה רוב קוד התקשורת שאני כותב לא משתמש ב jQuery אלא ישירות ב XMLHttpRequest. התמיכה בדפדפנים טובה, יש את כל היכולות והממשק מאוד נוח. רק מה, יש מספר כותרות שצריך לזכור להוסיף לבקשות כדי שספריות צד השרת שלכם ידעו למה אתם מתכוונים כשאתם שולחים הודעה, כותרות ש jQuery מוסיף באופן אוטומטי לכל הודעה.
לא הרבה מפתחים מתאהבים ברדוקס מהרגע הראשון, ובמיוחד בולט הדבר בקורסים כשאנשים מסתכלים בפרצוף עקום על הספריה המוזרה הזאת. אבל האמת היא שחווית הפיתוח עם רדוקס היא ממש פשוטה כשניגשים נכון לדברים. ניקח לדוגמא פיתוח משחקון בול-פגיעה. נסו להנות מהדרך.
כנראה שלא, והסיבה המרכזית היא חוסר שקיפות. ככל הנראה הוא יעשה הכל כדי למכור את האוטו, כולל להסתיר את כל הפגמים שלו. בעסקים שקיפות היא הדרך הטובה ביותר לייצר עסקאות איכותיות בהן כל הצדדים מרוויחים, אז למה שקיפות היא הדבר הראשון שעסקים מוותרים עליו?
טור דעה שהעלה להארץ מנכ"ל Experis קורא לממשלה לסבסד הכשרת עובדים להייטק. לשאלות שלי הוא לא ממש טרח להתיחס.
לרוב אני לא נכנס לקרוא עדכונים מקבוצות פייסבוק ומעדיף להסתפק בתמונות של החתולים בפיד הראשי. אבל מדי פעם הנורה של ה Notifications מושכת את תשומת לבי. זה קרה השבוע כשחבר העלה את הפוסט הבא לקבוצת "נגישות באינטרנט שאלות ותשובות".
כשאני רוצה לכתוב קוד מכוער (למשל כדי להספיק להכניס עוד פיצ'ר אחד לפני הדד-ליין) יש לי שיטה, או מספר כללים שעוזרים. לא תמיד זה יוצא מזעזע אבל אם מבצעים את כל הסעיפים האלה בצורה שיטתית אפשר להשחית כמעט כל מערכת.
למסמך קורות חיים יש מטרה אחת בלבד, והיא שמי שקורא אותו יזמין אותך לראיון עבודה. למי שקורא את הקו"ח שלך יש גם מטרה אחת בלבד, והיא למצוא מועמד שיתקבל לעבודה. חיבור שני החלקים מלמד אותנו שמסמך קו"ח צריך לספר את מה שיגרום למעסיק שמחפש עובד כמוני להתקשר אליי.
בשביל זה הכרחי שהקו"ח יספרו עליכם את הדברים שמעסיקים רלוונטים רוצים לשמוע.הנה כמה רעיונות לסעיפים שרוב האנשים שוכחים להכניס לקו"ח וחבל.
בעולם התכנות המודרני הכולל גישה לאינטרנט מצד אחד וכלי פיתוח עם השלמה אוטומטית מצד שני, כתיבת קוד היא כבר לא בעיה כזו גדולה. ארגון קוד לעומת זאת זה סיפור אחר לגמרי. השאלות המעניינות הפכו להיות באיזה כלים להשתמש (PHP או node.js? בסיס נתונים טבלאי או NoSql? ובאיזה שפת תכנות?), איך לארגן את הקוד לקבצים ולמחלקות ואיך לכתוב קוד שיהיה קל לתחזוקה ולבדיקה.
את התשובות לשאלות אלו לא תמצאו ב Stack Overflow, מאחר ולכל פרויקט השיקולים שלו והמשאבים שלו. בתוכנה לאדם שמקבל החלטות כאלו קוראים ארכיטקט, או מעצב תוכנה. אבל האמת היא שמדובר בסולם שקצה אחד שלו הוא המתכנת המתחיל והקצה השני הוא הארכיטקט הבונה פתרונות מורכבים לארגון קוד במערכות גדולות.
אחד הצירים החשובים לפיתוח קריירה כמתכנתים הוא סולם הארכיטקטורה. הנה מספר טכניקות שעזרו לי להתקדם בציר זה.
הצרה עם בעיות ביצועים היא שהרבה פעמים קשה למצוא את הגורם, וכשכבר מוצאים הרבה פעמים קשה לתקן. עבורי העובדה שב React יש דרך מאוד פשוטה למצוא ולתקן בעיות ביצועים היא אחת הסיבות המרכזיות לבחור ב Framework.
ב React יש לכם בסך הכל שני מקומות לטעות בכל הקשור לביצועים: או שאתם מרנדרים יותר ממה שצריך, או שפעולת render שלכם לוקחת יותר מדי זמן. מאחר וכמעט תמיד מדובר בבעיה הראשונה נתחיל מחיפוש render-ים מיותרים.
טעות מקרית בפרל הזכירה לי יכולת חזקה אך מבלבלת של השפה- התאמת ביטוי רגולרי בצורה מדורגת. הרעיון שיש לכם טקסט ארוך ואתם רוצים לבדוק את התאמתו לביטויים רגולריים חלק אחרי חלק, כאשר כל חלק ממשיך היכן שהקודם עצר. נראה את זה בקוד ואז גם תבינו למה התחביר כל כך מבלבל.