המשחק גו

המשחק מורכב מ180 אבני משחק בכל צד - שחורים ולבנים,
כל שחקן משחק בתורו אבן על אחד מהנקודות בלוח המשחק.
לוח משחק סטנדרטי הוא 9x9, 13x13 או 19x19.

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

מה כל כך מיוחד במשחק הזה?
שהחוקים פשוטים אך קשה מאוד לשלוט באופן מלא במשחק - זה די דומה לתכנות!

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

לכל מי שמתעניין אני ממליץ לנסות את המשחק וללמוד את החוקים שלו,
הוא מאוד קל ללמידה.

מה למדתי מהמשחק?

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

לראות את כל הלוח

מיקרו-מאקרו

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

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

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

לעבור ביניהם

תעבדו במיקרו אך תמיד תעשו זום החוצה לתמונת המאקרו.
בתצורת העבודה הזו אנחנו תמיד מבינים אך הקוד שאנו כותבים ישפיע על אחרים - על מפתחים, לקוחות או מערכות.
מה אם החלטנו לשמור קובץ json?
האם זה משנה מה נשים שם?
התשובה אולי תהיה - כן!
בשילוב עם YAGNI - Ya ain't gonna need it,
אנחנו לא צריכים לכתוב את כל הקוד בחשיבה ש”מישהו ישתמש בזה מתישהו” אבל בתצורה שבמידה ואם מישהו כן ישתמש בזה אז הקוד שלנו יהיה מסודר, מובן, מתועד וקל לשימוש.

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

חשיבה וויזואלית קדימה

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

בתוכנה נשתמש בזה בחשיבה שלנו כל הזמן:

• לחשוב על ווריאציות
• להשוות סיכונים
• לנסות להגיע לכל מקרי הקצה
• לדעת כיצד הממשקים ייראו

עיצוב תוכנה

בעיצוב תוכנה ניתן להשתמש ביכולת החשיבה הוויזואלית כדי לדמיין כיצד ה-API שלנו ייראה,
כיצד ישתמשו בו ולאן הוא יוכנס.

דוגמא - מערכת ספרים

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

יש כאן כמה בעיות שאני צופה מראש:

• גודל התוכן
• שימוש באלגוריתמים יעילים
• מתן יכולת קלה לחיפוש

ממשק משתמש

אז בשימוש היכולת הוויזואלית ניתן להתחיל מכל מקום - מההתחלה או מהסוף.
ההתחלה תהיה הממשק משתמש שהלקוח משתמש בו:

קריאות API

ואז נצטרך לחשוב על API תקשורתי בין הממשק משתמש לשרת.
נוכל להעביר את הבקשה ע”י בקשת GET:
GET https://myserver:434/v1/searchby/freetext?text=It's the possibility of having a dream come true

כמובן זה ייצטרך לעבור encode:
GET https%3A%2F%2Fmyserver%3A434%2Fv1%2Fsearchby%2Ffreetext%3Ftext%3D%22It%27s%20the%20possibility%20of%20having%20a%20dream%20come%20true%22

מה נחזיר משם?
נוכל להחזיר רשימה של ספרים עם אחוז כמה מהספר הזה נמצא מתאים למשפט:

1
2
3
4
5
6
7
8
9
10
11
12

{
    "Books":[
        {
            "Name": "The Alchemist",
            "Result": 99
        },
        {
            "Name": "alice in wonderland",
            "Result": 57
        }
    ]
}

וכבר יש לנו תמונה של המערכת שלנו מבלי שכתבנו שורת קוד אחת!

כדי לנצח צריך קצת יותר מהיריב

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

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

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

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

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

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

אז בואו נלמד כמה דברים ממיקלאנג’לו ו-גו:

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

אז מי היריב שלנו כאשר מדברים על תוכנה?
אנחנו!

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

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

פתגמים

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

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

כמובן שלא כל פתגם גו יתורגם ישירות לתוכנה,
זו מטאפורה טובה אך לתוכנה יש לנו פתגמים משלנו:

• העדף הכלה מאשר הורשה
• אל תקרא לנו, אנו נקרא לך
• תחשב פעמיים, תחתוך פעם אחת
• תמיד תתכנתו כאילו המתכנת הבא הוא משוגע שגר לבד ביער ויודע איפה אתם גרים!

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

להנות

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

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

מי שיודע להפיק את ההנאה מהמקצוע שלו יהיו לו חיי נחת וחיים מספקים יותר.

האם למדתם משהו מתחום אחר שעזר לכם בכתיבת קוד?

כנסו לדיסקורד ותשתפו אותנו!
בלינק:
https://discord.gg/WPVCxbw8

תודה על הקריאה :)