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

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

אז מה בכל זאת קורה ב-8 השנים הבאות? שני דברים:

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

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

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

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

הפרויקט Pirate Weather שעלה לאחרונה לאוויר הספיק לקבל כבר מעל 500 לייקים ברדיט. כתב אותו דוקטורנט בשם אלכסנדר ריי והמטרה שלו פשוטה: להחזיר נתוני מזג אוויר באותו פורמט JSON כמו אתר Dark Sky, אחרי שאפל קנו את דארקסקיי וסגרו את השירות.

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

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

1. הוא בחר פרויקט שפותר לאנשים אמיתיים בעיה אמיתית: אנשים היו רגילים להשתמש ב Dark Sky API או שהיה להם קוד קיים שקורא JSON-ים מ Dark Sky, דארק סקיי נסגר ועכשיו יהיה להם פיתרון חלופי בלי עלות מעבר.

2. הוא בנה דף בית מאוד מסודר שמסביר בדיוק מה הסיפור של הפרויקט, מה כרגע עובד ואפילו הוסיף אילוסטרציה לארכיטקטורה.

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

4. הוא בנה דף Front End שמשתמש ב API ומראה את התחזית במקום מגוריכם.

5. הוא כתב פוסט מפורט שמסביר טכנית איך בנוי הפרויקט ובאיזה תשתיות הוא משתמש.

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

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

ובגלל זה כל כך חשוב לשאול "איך יודעים מה צריך לעשות?" ו"איך משתפרים בזה?"

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

1. הגעתי לבעיה כשהיתה לי היכרות טובה מאוד עם הקוד.

2. הגעתי לבעיה כשהיתה לי היכרות טובה מאוד עם עולם התוכן.

3. הגעתי לבעיה אחרי שכבר פתרתי בעיות דומות בעבר.

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

וזה מביא אותנו לשאלה היותר מעניינת - "איך משתפרים בזה?". חיבור שלושת התנאים והיפוך הסדר ילמד אותי ש:

1. כדאי לפתור כמה שיותר בעיות

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

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

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

אחד הטרנדים החמים היום בפיתוח הוא Serverless או פיתוח ללא קוד Back End, או יותר נכון פיתוח בלי מערכת Back End מלאה שמטפלת בכל ההיבטים של צד השרת. פיתוח Serverless יהיה יותר דומה לפיתוח Micro Services, אבל בצורה שכל סרביס רץ בתוך סביבת ריצה מנוהלת ומבוקרת משלו.

שירות AWS Lambda הוא דוגמה לפיתוח מסוג זה. הוא מאפשר לנו לכתוב קוד (פונקציה) שירוץ בכל פעם שקורה משהו ויחזיר תוצאה למי שקרא לו. באמצעות חיבור הפונקציה לשירות שנקרא API Gateway אנחנו הופכים את אותה פונקציה לזמינה מכל מקום ברשת למרות שהיא עצמה בסך הכל פונקציה קטנה אחת ולא מערכת Back End מלאה.

במדריך זה אראה איך להקים פונקציה (לא משהו מסובך היא רק תחזיר Hello World בדוגמה שלנו) ולחבר אותה ל API Gateway וכל זה באמצעות שימוש בכלי שורת הפקודה של AWS בלבד.

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

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

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

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

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

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

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

"אני לא יודע איך לעשות X" זו עמדת ברירת המחדל, המצב ההתחלתי. יש המון המון דברים שאני לא יודע וזה לא מעניין לדבר עליהם.

אבל ברגע שהנושא עולה בפעם הראשונה זה משנה הכל.

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

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

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

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

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

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

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

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

ועכשיו ברצינות.

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

1. להחליף סיסמאות כל X זמן וכמובן כל פעם שתוכנה אוטומטית זיהתה סיסמה חלשה.

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

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

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

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

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

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