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

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

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")

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

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

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

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