ארכיטקטורת תוכנה טובה היא תלוית קונטקסט,
מנתחת trade-offs שפותרים את הבעיות בצורה שונה על פני הרבה סביבות.
נכון? ככה לימדו אותנו. אין פתרון קסם "הכי טוב" לבעיה.
כמעט אף פעם אנחנו לא נצליח למצוא חוק כללי שמתאים לכל הסיטואציות.
האמנם?
חוק קונוויי הוא אחד החוקים שלא מצאתי הרבה אנשים שסותרים את החשיבות שלו באופן כללי.
הוא מסוגל להשפיע על כל סוג של מערכת,
והוא מספיק חזק כדי לשבור כל מערכת אם מנסים להילחם בו
מהו חוק קונוויי?
ההגדרה הכי טובה של החוק היא על ידי המגדיר הראשוני שלו, Melvin Conway
כל ארגון אשר מעצב מערכת, בסופו של דבר יפתח מערכת שהמבנה שלה הוא העתק של העץ תקשורת של הארגון
Melvin Conway (תרגום חופשי שלי)
חוק קונוויי הוא תצפית שארכיטקטורת מערכות תוכנה דומות מאוד למבנה של הארגון שמפתח אותן.
ולמרות שהחוק מוזכר בהקשר של מערכות תוכנה, הוא תקף לכל סוג של מערכת.
מה המשמעות של החוק?
נניח ואני כותב קוד חדש,
אשר צריך להתממשק עם interface או עם component שמישהו אחר כתב.
אז אם קל לי לדבר עם המחבר של הקוד, אז אוטומטית יקרו שני דברים:
- לי תהיה הבנה עמוקה וטובה יותר של הקוד שאני אמור להתממשק
- לקוד שלי יהיה יותר קל להתממשק עם הקוד.
זה לא רק ברמת קריאת הפונקציות, אלא גם הנחות המוצא של הקוד שלי והקוד שאני עובד איתו יהיו דומות,
כיוון שאני מסוגל לדבר עם המחבר שלו בקלות, סביר מאוד להניח שהבנת הבעיה והדרכים לפתרון שלה יהיו משותפות לשנינו.
אז איך חוק קונוויי משפיע על הארגון שלנו?
לעיתים קרובות אנחנו יכולים לראות איך אי הקשבה לחוק יכולה לעוות ארכיטקטורה של מערכת.
אם אנחנו נכתוב ארכיטקטורה שהיא מנוגדת למבנה ארגון הפיתוח שלנו, אז מתח יופיע במבנה של התוכנה שלנו.
אינטראקציות בין מודולים, שבתכנון היו אמורות להיות פשוטות,
הופכות להיות מאוד מורכבות, בגלל שהצוותים שעובדים על המודולים הללו, לא עובדים טוב ביחד.
פתרונות אחרים, אשר יותר פשוטים, לא נשקלים כיוון שהקבוצות פיתוח לא מדברות באופן שוטף.
כאשר עשרים מפתחים אשר יש להם תקשורת טובה עובדים על מערכת, אז חוק קונוויי מרמז שהם יפתחו מונולית'. זה בסדר, כיוון שחוק קונוויי לא מדבר על צוותים קטנים. רק כאשר אנחנו כבני אדם מגיעים לשלב שאנחנו צריכים לארגן את עצמנו לארגון עם היררכיות, אז חוק קונוויי נכנס לפעולה וצריך להשפיע על קבלת ההחלטות שלנו.
אז איך מתמודדים עם חוק קונוויי?
הצעד הראשון להתמודדות עם החוק הוא לדעת לא להילחם בו.
Martin Fowler נתן דוגמה נחמדה לזה. הוא מתאר ארכיטקט שכתב ארכיטקטורה של פרויקט גדול אשר יכלול שישה צוותים שונים, אשר נמצאים בערים שונות ברחבי ארה"ב. הארכיטקט אמר למרטין שההחלטה הראשונה הייתה שיהיו שש תתי מערכות שונות בפרויקט. הוא לא ידע בהתחלה אילו שש, אבל הוא ידע שחייבות להיות שש.
הדוגמה הזאת מדגימה את המשמעות הגדולה של מיקום פיזי על תקשורת אנושית.
גם אם צוותים נמצאים באותו בניין, אבל בקומות שונות, זה יהיה מספיק משמעותי כדי להשפיע על התקשורת של שני הצוותים הללו ברמה שאנחנו נצטרך להתחשב בזה כאשר נעצב את המערכת שלנו.
ככל שהצוותים שלנו רחוקים יותר: ערים שונות, מדינות שונות, זה רק יקטין את התקשורת הסדירה וישפיע יותר.
אי התאמה שכיחה עם חוק קונוויי היא צוותי Activity Oriented.
צוותים אשר מאורגנים לפני שכבות תוכנה (צוותי פרונט, צוותי בק, צוותי DB, וכו'), שכל צוות עובד על כמה פיצ'רים במקביל, על החלק שלו.
מבנה כזה מוביל לעיצוב תוכנה שמכונה שכבות, כלומר תהיה לנו את שכבת הפרונט, שכבת הדומיין ושכבת ה-DB, לדוגמה, וזה בעייתי בגלל שפיצ'ר צריך שילוב פעולה גבוה בין כל השכבות שלו.
בדומה, חלוקה של צוותים לפי הפייפליין של הפיתוח (ניתוח, עיצוב, פיתוח, בדיקות) יביא להרבה העברת מידע (hand 0ff) כדי להביא פיצ'ר לפרודקשיין.
לעצב את הארגון ולא את התוכנה
בעשור האחרון, בעקבות עליית הפופולריות של microservices אנחנו רואים התאמה שונה לחוק קונוויי. במקום לעצב את התכונה שלנו בהתאם למבנה הארגון, אנחנו נשנה את מבנה הארגון כך שיתאים למבנה התוכנה שאנחנו רוצים שיהיה לנו. השיטה הזאת נקראת Inverse Conway maneuver
השימוש ב-microservices מאפשר לנו להרכיב צוותים אשר יש בתוכם את כל בעלי התפקידים כדי לכתוב את ה-microservice.
על ידי ארגון צוותים אוטונומיים בצורה הזאת, אנחנו מממשים את חוק קונוויי כדי לעודד פיתוח סרביסים אוטונומיים שאפשר לפרוס בלי תלות בסרביסים אחרים.
מגבלות החוק
למרות שחוק קונוויי הוא מאוד חזק, הוא לא כל יכול. אם יש לנו מערכת קיימת אשר לא תוכננה לפי חוק קונוויי, לנסות לשנות אותה או להכיל את Inverse Conway Maneuver לא יעבוד בצורה אוטומטית.
יש יותר סיכוי שזה יצור חוסר התאמה בין מפתחים לקוד שהם אחראים עליו, מה שיצור עוד חיכוך.
במערכות כאלו הדרך היא לעבוד ביחד עם חוק קונוויי והמערכת הקיימת. כלומר כאשר אנחנו מתחילים לכתוב ארכיטקטורה חדשה, או שינויים ארגוניים, אנחנו צריכים לקחת בחשבון גם את חוק קונוויי וגם את המערכת הקיימת.
וכמובן, לעשות צעדים קטנים, אשר יאפשרו לקבל פידבק יותר מהיר.
קריאה נוספת
שני ספרים נהדרים שמדברים על הנושא הם Agile IT Organization Designו- Team Topologies.
אם אתם מעדיפים להאזין במקום לקרוא, אז יש פרק מעולה בפודקסט ThoughtWorks Technology Podcast
