מה ההבדל בין ארכיטקטורה לעיצוב קוד

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

עיצוב קוד - מה קורה בתוך הקומפוננטה

עיצוב קוד (code design) עוסק במבנה הפנימי של יחידת קוד אחת - איך מחלקה אחת בנויה, אילו מתודות יש לה, איך פונקציות מתחלקות אחריות ביניהן. זו הרמה שבה חיים עקרונות כמו SOLID ותבניות עיצוב כמו Factory, Strategy או Observer. השאלה המרכזית כאן היא "האם הקוד הזה קריא, ניתן לבדיקה, וקל לשנות מבלי לשבור דברים".

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

ארכיטקטורה - מה קורה בין הקומפוננטות

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

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

למה הבלבול ביניהם מזיק

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

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

איך יודעים באיזו רמה אתם נמצאים

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

שאלה שנייה שעוזרת - "האם ההחלטה הזאת חוצה גבול של תהליך (process boundary) או רשת?" אם שני חלקי קוד רצים באותו תהליך וקוראים זה לזה כפונקציות רגילות, זו לרוב שאלת עיצוב קוד. אם הם מתקשרים דרך API או תור הודעות, זו כמעט תמיד שאלה ארכיטקטונית.

למה שתיהן חשובות באותה מידה

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

לסיכום

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

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

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