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

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

הסיבות הקלאסיות לחוב טכני כוללות-

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

2. כתיבת קוד ללא בדיקות או ללא תיעוד

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

4. אי שידרוג תלויות כשגירסאות חדשות יוצאות

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

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

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

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

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

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

לטוויטר קראו בהתחלה Odeo והמטרה שלהם היתה להפוך פודקסטים לנגישים יותר.

והבצק פליידו שהילדים לשים כל היום? הוא בכלל התחיל בתור חומר ניקוי לקירות.

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

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

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

משמעות הקיצור DRY היא Don't Repeat Yourself, ובהקשר של קוד אנחנו מתכוונים לא לחזור על אותו קטע קוד שוב ושוב. אבל מה אם קטע הקוד הזה הוא שורה אחת?

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

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

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

תשוו את זה לכל הדברים שאנחנו לא עושים בפרויקט, אבל חשובים לא פחות:

1. כתיבת תיעוד.

2. עריכת היסטוריית הקומיטים בגיט כדי שתשקף נכון את העבודה שעשינו.

3. כתיבת בדיקות.

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

5. טיפול במקרי קצה.

6. טיפול בשגיאות ויצירת Flows מתאימים למשתמשים במצבי שגיאה.

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

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

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

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

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

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