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

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

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

אבל יש שתי בעיות ברורות עם האנלוגיה הזאת:

1. מסלול הליכה רגלי מרגיש פחות או יותר אותו דבר לכל אחד שעובר בו. "מסלול הליכה" לימודי הוא משחק אחר לגמרי. מה שאחת מצליחה ללמוד בשבוע ייקח לאחרת חודש וחצי.

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

כן כדאי להכיר את נקודות העניין המרכזיות על המסלול: כדאי להבין שכשאתם באים ללמוד פיתוח Front End תצטרכו להיות מסוגלים לבנות דף נחיתה פשוט, להתאים אותו למובייל, לבנות אתר עם מספר דפים שרץ על שרת מקומי, להפוך אותו ל Single Page Application על השרת המקומי, להבין איך עובד Ajax ולהוסיף מידע דינמי שמגיע מצד השרת. זה מסלול. אבל אין מפה ספציפית שתביא אתכם מנקודה לנקודה. אנחנו יוצאים לדרך עם תרמיל והבנה בגדול של היעד הבא, ומבינים שכל אחד יגיע לשם בדרך קצת אחרת.

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

1. איך אני מבזבז זמן על תיקון כזה כשיש כל כך הרבה באגים קריטיים לפתור?

2. מה יגיד הראש צוות? המנהל מוצר? הבוס?

3. ומה אם התיקון שלי יכניס מלא באגים חדשים?

4. עדיף להכניס את המשימה לתוכנית עבודה ולהתמודד איתה בצורה מסודרת.

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

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

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

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

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

״למה לי להתחיל פרויקט מאפס? עדיף להשתמש ב create-react-app ולקבל שלד לפרויקט שכבר כולל את כל מה שאני צריך?״

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

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

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

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

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

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

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

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

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

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

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

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

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

אתם יכולים לראות את הסידרה שכולם מדברים עליה (ואז בטוח יהיה לכם עם מי לדבר ותרגישו בעניינים), או שתבחרו סידרה שאף אחד לא שמע עליה.

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

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

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

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

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

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

נזכרתי בסיפור הזה כשנתקלתי במקרה בקוד בסגנון הזה, השפה היא רובי:

BookCategory.all.select {|bc| bc.category.nil? }

הקוד עובד ושולף את כל השורות מטבלת book_category שהרשומה המתאימה להן מטבלת categories לא קיימת. אבל היום לא הייתי מעז להעלות קוד כזה למערכת אמיתית - כמות הגישות לבסיס הנתונים תלויה במספר השורות בטבלת book_category ולכן עשויה להיות גדולה מאוד.

במקום זה אפשר להשתמש בשאילתה שקולה לחלוטין שנראית כך:

BookCategory.left_outer_joins(:category).where("categories.id is null")

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