הייטק
ליצירת דיון חדש בחרי את הפורום המתאים מתוך הלשונית ”דיונים”
מובילה:
- Organized by
-
-
Clean Architecture – פוסט העשרה
-
Clean Architecture – פוסט העשרה
**Clean Architecture** 📰
לאחרונה יצא לי להרצות בשתי פורומים שונים על ארכיטקטורה שהתוועדתי אליה באחת העבודות הקודמות שלי.
התנסיתי בה באופן אישי, במשך כמה חודשים טובים, בארגון שקיבל החלטה להעביר service מ .Net Famework ל .NetCore 3.x, וה CTO בחברה לקח כמה החלטות ארכיטקטוניות ובכללם ללכת על הארכיטקטורה הזאת, פלוס עוד כמה מתודולוגיות פיתוח ו design patterns שאפרט בסוף.▶ **תוכלו למצוא בתגובות או בבלוג, את המצגת וגם וידאו הקלטה של ההרצאה** ◀
היא הוצגה ע”י רוברט ססיל מרטין, AKA “דוד בוב”, שמוכר ביותר בפיתוח עקרונות רבים לתכנון תוכנה ובהיותו מייסד המניפסט האג’ילי. בנוסף חמישה מעקרונותיו של מרטין נודעו יחד כעקרונות ה SOLID
הארכיטקטורה מכסה הרבה קונספטים בעייתיים ולכן היא קצת קשה להכלה,
היא לוקחת הרבה מאוד בעיות בתכנות ומנסה לפתור אותםבאופן אישי – מה שהכי אהבתי בארכיטקטורה, הקלות שבה אפליקציה עוברת frameworks.
אם למשל ניקח כדוגמא שירות דוטנט, נוכל להמיר אותו בקלות לאפליקציית אנגולר, ולקחת ממנו את החלקים הרלוונטיים כמו שכבת המודלים הנקייה, או business rules שמעוניינים בהם. פשוט נדרש לעשות התאמות נדרשות למעבר בין שפות C# ל TS
אין שום external resource dependency בשכבות הנ”ל, הקוד הוא pure לגמרי, ומשקף נטו את ה essence של האפליקציה.
הקונספט המרכזי של הארכיטקטורה של בוב, הוא הקו של קוד נקי pure code ככל שניתן,
לדעתי זהו שיקול שאמור להיכלל בקבלת כל החלטה על ארכיטקטורה שהיא.
בעידן שבו יש סחרור טכנולוגי, זה הופך את זה לשיקול מרכזי.בעיניי, בקונספט הזה, זה לא חייב להיות ארכיטקטורה שחייבים להיצמד, אלא החלטה שהארגון מקבל ומנחיל לעובדים כמו ה solid principals .
אני הייתי מוסיפה פשוט ל SOLID את סיומת PC כדי להזכיר את עקרון ה pure code בכל כתיבה בכל קובץ שהוא במערכת.למה בכלל ארכיטקטורה?
ארכיטקטורות מאפשרות ניתוק יחידות שונות של הקוד שלך בצורה מסודרת ומנוהלת. באופן זה קל יותר להבין, לשנות ולבדוק את הקוד.
בארגון גדול, שבו צוותים שונים נוגעים באותו קוד, ומתכנתים מתחלפים בקצב, ארכיטקטורה עוזרת להחיל קונבנציות ארגוניות מקובלות אשר מקלות על נראות, קריאות ותחזוקת הקוד לטווח הרחוק.יש כמה ארכיטקטורות דומות כמו זאת,
ולכולם אותה מטרה שהיא Separation of Concerns. וכולם משיגים הפרדה זו על ידי חלוקת התוכנה לשכבות.הדבר שהכי מאחד אותם הוא שכולם מאפשרות לך לייצר ארכיטקטורה שהיא free of cycles –
no circular dependency, ועדיין מצליחה לתקשר בין השכבות בצורה אפקטיבית.מה שמוודא שכאשר יש שינוי בקוד, הוא יתקל במהרה firewall , בקצה של השכבה הנוכחית שבה מעניין השנוי, מאשר להתפשט לעבר כמה חלקי קוד, breaking component after component..
Architecture Goals:
Testable
Independence from Framework
Independent of UI
Independent of Databases, Libraries
Independent of any External Agency (Security, scheduling, etc)למעשה הכללים העסקיים שלך פשוט לא יודעים שום דבר על העולם החיצון, על הספריות, הפריימוורק, פלטפורם כזה או אחר, tools & drivers שמשתמשים בתוכנה, חבילות חיצוניות ועוד.
Core Layers מבודדים לחלוטין מהעולם החיצון.
ואז, כל שינוי גרסה בתלויות, או הפסקת תמיכה בפיצ’ר מסויים, או מעבר טכנולוגי כזה אחר, מצמצם את רמת ההשפעה שלו לשכבות העליונות בלבד, העוטפות את שכבות ה pure code – business rules.אצרף בתגובות את הלינקים לוידאו ולפוסט המלא בבלוג.
אשמח לשמוע את תובנותיכם.
-
7 תגובות
-
-
פוסט מושקע ומחכים ביותר!
מודה שלא קראתי ממש כל שורה 😊
אבל לקחתי את הרעיונות העיקריים.
תודה! -
**המשך תגובה**
לדעתי, אפשר להחיל ארכיטקטורה כזו רק בפרויקט חדש,
או כמו בדוגמא שלכם – ריפקטורינג של סרביס.
קשה לי לראות איך אפשר לבצע ריפקטורינג לקוד קיים כך שיקיים את עקרונות הארכיטקטורה.
בנוסף,
יישום ארכיטקטורה כזו דורש משמעת עצמית/ארגונית קשוחה מאד של המפתחים.
בעבר, עבדנו על הכנסת עקרונות ה clean code, כפי שמביא אותם Uncle Bob,
וזה היה אתגר טכנולוגי וארגוני לא קל. (שגם לא כ”כ צלח לבסוף)ניקיון של קוד קיים הוא דבר קשה, ותחת לחץ של דד-ליינים – כמעט בלתי אפשרי.
בנוסף, בלא מעט מקרים ההשקעה הנדרשת כדי ליישם את עקרונות ה clean code לא הצדיקה את התועלת שנפיק מכך.מענין אותי לשמוע,
האם בטווח של חודשים/שנים מאז שיישמתם את הארכיטקטורה את יכולה להצביע על שיפור משמעותי בכתיבה/תחזוקה של הקוד?-
זה שאלות שנשאלות שוב ושוב. תמיד יהיה דיון על ה extra efforts שכדאי להשקיע מול value שנקבל.
זוהי ה שאלה ולכן כל עניין לגופו.
תהליך ניקיון של קוד קיים הוא באמת קשה, אך לא בלתי אפשרי. ותמיד אפשר להחליט איפה הגבול, ובמה מתרכזים. מה שנקרא תפסת מרובה…
וההשקעה של ניקיון קוד תמיד תצדיק את המאמץ ועל זה אין עוררין. כשקוד נקי, כתוב נכון, מסודר, אז ה maintenance שתופס 80 % מהזמן שלנו כמתפתחים, יהיה הרבה יותר פשוט ואולי ייחסכו דברים שבקוד גרוע יצוצו שוב ושוב.
זה גם יקל על מעבר מתכנתים, הכנסת חדשים לצוות, פיתוח פיצ’רים חדשים ויכולת התבססות על הקוד הקיים.
מה שכן, יהיו שיחלקו עלי, אבל מדובר בעניין של כל דבר לגופו.
לסטארטפ קטן באמת לא שווה להשקיע בזה, קודם כל הוא צריך להביא value שיצדיק את הנ”ל.
בד”כ לחברה גדולה, על מסלול התפתחות, אין סיבה שלא.
ולגבי הטמעת הארכיטקטורה, אז בסרטון וגם בפוסט בבלוג אני מציינת בהקדמה את העניין הזה, כי זה שאלה טובה ונכונה. ולדעתי האישית אפשר לקחת את זה כעיקרון נוסף כמו ה SOLID. מצטטת בתגובת המשך:-
הקונספט המרכזי של הארכיטקטורה של בוב, הוא הקו של קוד נקי pure code ככל שניתן, והוא שיקול שאמור להיכלל בקבלת כל החלטה על ארכיטקטורה שהיא.
בעיניי, בקונספט הזה, זה לא חייב להיות ארכיטקטורה שחייבים להיצמד, אלא החלטה שהארגון מקבל ומנחיל לעובדים כמו ה solid principals .
אני הייתי מוסיפה פשוט ל SOLID את סיומת PC כדי להזכיר את עקרון ה pure code בכל כתיבה בכל קובץ שהוא במערכת.
כלומר ננסה לכתוב קוד נקי מתלות במשאב חיצוני.
למשל להימנע מלשים על השדות attributes של JSON ושל MVC וואלידציות מכל מיני סוגים, והורשות שונות בתלויות חיצוניות מחבילות שונות.
-
-
-
הפוסטים מדהימים ובאמת מייעלים
שלא מן העניין, מעניין אותי איפה את עובדת?
-
תודה! אני כרגע בגיגיה, חברת בת של סאפ. בתל אביב 🙂
עד למקום הבא 🤗
-
Log in to reply.
