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