לדלג לתוכן

מה זה DRY, KISS ו-YAGNI - שלושה עקרונות שכל מפתח משתמש בהם בלי לדעת

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

DRY - אל תחזור על עצמך

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

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

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

KISS - תשמרו את זה פשוט, טיפש

הראשי תיבות KISS אומרים Keep It Simple, Stupid. העיקרון הזה נולד בהנדסה צבאית, לא בתכנות, אבל הוא מתאים בול. הרעיון - הפתרון הפשוט ביותר שעובד הוא כמעט תמיד עדיף על פתרון מסובך, גם אם המסובך "אלגנטי" יותר על הנייר.

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

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

YAGNI - לא תצטרכו את זה

הראשי תיבות YAGNI אומרים You Aren't Gonna Need It, ולדעתי זה העיקרון הכי חשוב מבין השלושה, כי הוא נוגד את האינסטינקט הטבעי של מתכנתים טובים. יש נטייה לחשוב קדימה - "מה אם בעתיד נצטרך לתמוך גם בתשלום בביטקוין?", ואז לבנות תשתית שלמה בשביל תרחיש שאולי לעולם לא יקרה.

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

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

איך שלושת אלה עובדים ביחד

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

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

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

לסיכום

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