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

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

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

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

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

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

בכל מוצר תוכנה שאני יכול לחשוב עליו שידרוג בין גירסאות קרובות הוא הרבה יותר קל מאשר שידרוג בין גירסאות רחוקות. המעבר מריילס 5.1 ל 5.2 הולך להיות הרבה יותר פשוט מאשר קפיצה מ-4 ל-6. אותו דבר עם אנגולר, ריאקט, Java או כל טכנולוגיה אחרת.

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

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

אבל לפני הכל ולממהרים - זה הלינק לקורס: https://www.tocode.co.il/bundles/react

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

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

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

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

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

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

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

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

אם לא הצלחת להגיע למטרה שרצית, אולי שווה לנסות שיטה אחרת.

אחד השילובים שאני יותר אוהב בפיתוח הוא Redux ו Web Sockets. זה עובד ממש פשוט ויפה יחד: כל פעם שמגיע אירוע מבחוץ דרך ה Web Socket, יהיה לנו מידלוור שיתרגם את האירוע לאוביקט Redux Action, האוביקט ייכנס למערכת דרך ה Reducers ובאופן אוטומטי המסך יתעדכן כי ריאקט יזהה את השינוי וימשוך את המידע החדש.

בואו נכתוב שלד קצר להמחיש את הרעיון באמצעות שרת Firebase.

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

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

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

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

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

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

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

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

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

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

ודרך טובה מאוד להפוך למתכנתים טובים יותר היא לאמץ את המיינדסט של המדריך גם על משימות תכנות בעבודה השוטפת.