טיפים קצרים וחדשות למתכנתים
מאז ומעולם לימדו אותי שכשאנשים מדברים כדאי לרשום: החל מבית הספר (שם המורה ״הכתיבה״), דרך הצבא וכמובן במקומות העבודה בתור שכיר. כשהגעתי בטעות לפגישה בלי מחברת תמיד היה מי שהתנדב לתת לי דף ועט, בצירוף מבט שלא משתמע לשתי פנים — אם לא תכתוב איך תזכור? אבל לאחרונה אני מתחיל לשמוע דעות שונות מאותם אנשים שלא כותבים ומתעקשים שהדרך שלהם היא הנכונה. אין לי תשובה אחת אבל כן יש רשימת בעד ונגד, ומקום בסוף לשתף את הטיעונים שלכם.
אנגולר או ריאקט? ג׳אווה או .NET ? למי לא קרה שהתחלתם לכתוב קוד בטכנולוגיה מסוימת רק בשביל למצוא את עצמכם שנים (או חודשים) אחרי זורקים הכל לפח ומשכתבים במקרה הטוב, או נשארים עם טכנולוגיה מיושנת ומבזבזים זמן ״שיפוצים״ כשברור לכם שהמודל כולו שבור? בחירות טכנולוגיות והחלטות שאנו עושים בתחילת הדרך יכולות להשפיע על המשך חיי הפרויקט לטוב ולרע.
כשדן אברמוב הסביר על הסיבות לפיתוח רדוקס, אחת הסיבות שהוא ציין בקצרה היתה הקושי לשתף קוד בין מחסני מידע (Stores) במימוש הקלאסי של פלוקס. במבט ראשון לא כל כך הבנתי על מה הוא מדבר אז הלכתי לכתוב קצת קוד שיעזור להבהיר את הנקודה.
ב ES5 לא היה תחביר מיוחד להגדרת מחלקות ולכן ממילא הגדרת מחלקה יחידנית (כזו שקיים ממנה רק אוביקט יחיד) היתה מיותרת. פשוט מגדירים אוביקט במקום פונקציה. האם נוכל לבצע טריק דומה בכתיב המחלקות החדש של ES6?
הנה סיפור קצר מקורס בסיס שלימדתי בשבוע שעבר. באחד התרגולים ביקשתי מהתלמידים למצוא כפולה משותפת מינימלית (lcm) כדי לתרגל עבודה עם לולאות. הפתרון שהצגתי היה די פשוט ונראה כך:
עיתון הארץ סיפר השבוע על תלמידות תיכון שהגיעו לצילום בית ספר בלבוש שלא תאם את ציפיות המורים ולכן התבקשו להסתתר מאחורי תלמידים אחרים. "כאשר ניסינו להיאבק, אמרו לנו שאלה החוקים ואין מה לעשות”
לאחרונה עבדתי עם לקוח על ויזואליזציה של מבנה נתונים מסוג עץ (למשל עץ של קבצים ותיקיות). ממשק זה ממחיש את היתרונות של ריאקט ושל חלוקה לפקדים, מאחר וכל הצמתים בעץ הינם פקדים מאותו הסוג. נתחיל עם קצת קוד כדי שיהיה על מה לדבר.
כשאנחנו חושבים על עיצוב קוד (Code Design) מיד עולה לראש עולם המונחים מונחה העצמים: ירושה, כימוס, פולימורפיזם וכמובן מחלקות ותבניות עיצוב, אבל האמת היא שאפשר לכתוב קוד מודולרי ונקי גם ללא שימוש במחלקות. במיוחד נכון הדבר בשפות תכנות המתיחסות ברצינות לפונקציות ולהרכבה שלהן כפי שנראה בדוגמא הבאה.
הבעיה עם תקרת הזכוכית היא השקיפות שלה: מתכנתים מוצלחים לא מעלים בדעתם שהעדר תואר אקדמי יכול לעכב את ההתפתחות המקצועית שלהם. בעוד שתואר אקדמי אינו הדרך הטובה ביותר להכנס לשוק העבודה, בשלב מסוים כשאתם כבר בשוק תואר הוא מקפצה הכרחית להמשך ההתקדמות שלכם מהסיבות הבאות:
ספריית Tk הפכה לסטנדרט של פיתוח ממשק משתמש גרפי לסקריפטים בפרל, אך בגלל מודל המחלקות של פרל פיתוח ממשק גרפי מונחה עצמים יכול להרגיש מסורבל. כך נראית התבנית שלי לפיתוח מונחה עצמים ב Tk שכדאי גם לכם לאמץ.