למה כדאי להמציא את הגלגל מחדש?

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

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

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

מפתחים רואים בקוד מוכן מובן מאליו

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

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

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

return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});

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

תחזור לשורשים

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

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

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

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

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

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

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

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

להמציא מחדש את הגלגל הזה

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

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

מקור: www.habr.com