אמ;לק

לאחרונה סיימתי את הספר "The Pragmatic Programmer". בהתחלה קצת חששתי כיוון שזהו ספר די ישן, ולא הייתי בטוח האם הוא עדיין רלוונטי. התשובה היא כן, ובגדול. הספר לא מלמד איך לקודד, אלא איך לחשוב ולהתנהג כמו איש מקצוע שמפתח תוכנה - אומן (Craftsman). הפוסט הזה מסכם 5 עקרונות על-זמניים מהספר, שמפרידים בין מתכנת טוב למקצוען אמיתי, ואיך הם מתחברים ליומיום של כל אחד מאיתנו.

מתי בפעם האחרונה עצרתם לחשוב?

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

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

---

עקרון 1: אל תשאירו חלונות שבורים (Don't Leave Broken Windows)

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

Don't leave 'broken windows' (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered.

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

עקרון 2: ידע צריך להיות במקום אחד (DRY - Don't Repeat Yourself)

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

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system

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

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

עקרון 3: תכנתו בכוונה, לא במקרה (Don't Program by Coincidence)

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

Rely only on reliable things. DOn't depend on assumptions.

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

עקרון 4: השקיעו בפורטפוליו הידע שלכם (Invest in Your Knowledge Protfolio)

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

Learn at least one new language every year

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

עקרון 5: המבחן הוא המשתמש הראשון של הקוד (Testing is Your First User)

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

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

---

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

אם הגעתם על לכאן, אתם בטח מבינים שהמסר של "The Pragmatic Programmer״ עמוק יותר מסך העצות הטכניות שלו. הוא קורא לנו לקחת בעלות (ownership), להתייחס לפיתוח תוכנה כאומנות (craft) ולא כעבודה בפס ייצור, ולהיות גאים בתוצרים שלנו.

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