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

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

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

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

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

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

4. לקחת פרויקט קוד פתוח ולנסות לנחש איך הם התמודדו עם בעיה מסוימת (למשל איך gon מעביר את המשתנים מריילס ל JS). אחרי זה מסתכלים בקוד שלהם ורואים אם צדקתם.

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

יש לכם רעיונות נוספים? מוזמנים לשתף בתגובות.