پنج سخنرانی مفید در حوزه معماری نرم افزار

1.      Software Architectures, Team Topologies, and Complexity Science

جیمز لوئیس کسی که مفهوم میکروسرویس را معروف کرد در این سخنرانی به یک سوال اساسی جواب می‌دهد: راز تیم ‌های نرم ‌افزاری فوق‌ موفق چیست؟ او برای جواب دادن، سه تا علم را به هم وصل می‌کند: علم پیچیدگی، معماری نرم‌افزار، و چیدمان تیم‌ ها

جیمز می‌گوید که یک کلونی مورچه را در نظر بگیرید. هر مورچه به ‌تنهایی کار ساده ‌ای می‌کند، اما وقتی همه کنار هم قرار می‌گیرند، یک رفتار با هوش از کل کلونی دیده می‌شود که هیچ‌ کس از بالا دستور نداده است. تیم‌ های نرم‌ افزاری هم دقیقا همینطور هستند. یک معمار نباید از بالا همه جزئیات را برای تیم تعیین کند، بلکه باید شرایط را طوری فراهم کند که خود تیم‌ ها با تعاملات ساده‌ ، بهترین راه‌ حل را پیدا کنند.

در ادامه به مدل معروف توپولوژی تیم اشاره می‌کند که می‌گوید تیم‌ ها را باید به چهار دسته تقسیم کرد: ۱) تیم هایی که مستقیما برای کاربر ارزش میسازند، ۲) تیم هایی که به بقیه آموزش میدهند، ۳) تیم هایی که در بخش زیر ساخت فعالیت دارند، و ۴) تیم هایی که بخش های خیلی سخت سیستم را مدیریت میکنند. همچنین مشخص می‌کند که این تیم ‌ها چطور با هم تعامل داشته باشند؛ مثلاً با هم همکاری کنند یا به هم سرویس بدهند. این مدل به ما یک زبان مشترک می‌دهد تا بفهمیم چرا یک تیم با تیم دیگر مشکل دارد.

نکته‌ی کلیدی این است که ساختار تیم ‌ها، معماری نرم‌ افزار را می‌سازد. اگر تیم ‌ها را بر اساس کارهایی که انجام می‌دهند (مثل ثبت‌نام یا پرداخت) بچینید، معماری نرم ‌افزار هم به‌ طور طبیعی به بخش‌ های کوچک و مستقل (میکروسرویس) تبدیل می‌شود. هدف نهایی از همه این کارها، بهبود جریان (Flow) است، یعنی کد جدید هر چه سریع ‌تر و با کمترین دردسر به دست کاربر برسد.

این سخنرانی به ما میگوید که معمار نرم‌ افزار فقط نقشه‌کش نیست در واقع یک معمار خوب باید مثل یک باغبان باشد که خاک را آماده می‌کند و به تیم‌ها که در این مثال همان گیاهان هستند اجازه می‌دهد خودشان رشد کنند و تعاملات درستی با هم داشته باشند. معماری خوب، فقط کد تمیز نیست و حاصل تعاملات انسانیِ خوب است.

سخنران: James Lewis

لینک: https://www.youtube.com/watch?v=TgFSdEP9gcc

2.      Software Design, Architecture & Giving Clarity at Scale

این سخنرانی یک مصاحبه است، یعنی سه نفر نشستند پای میز و با هم حرف زدند. موضوعش هم خیلی جالبه: وقتی تیم نرم ‌افزاری کوچیکه، همه با همه حرف می‌زنند و همه می‌دانند که کد کجاست و چرا فلان جور نوشته شده. اما وقتی شرکت بزرگ می‌شود و تیم ‌ها به بیست تا چهل تیم مختلف تبدیل می‌شوند، اوضاع خیلی فرق می‌کند. توی این شرایط، بزرگ‌ ترین مشکل، خود کد نویسی نیست؛ مشکل این است که تیم‌ ها دیگر متوجه نمیشوند که معماری کلی سیستم دقیقا چیست و چرا بعضی تصمیمات گرفته شده است.

سم نیومن توی این صحبت می‌گوید که وظیفه یک معمار نرم ‌افزار در این مقیاس بزرگ، فقط کشیدن نقشه پشت‌ سر هم نیست. او باید طوری حرف بزند که هم مدیر عامل شرکت که می‌خواهد بداند چقدر زمان می‌برد متوجه شود، هم برنامه ‌نویس تازه ‌وارد که می‌خواهد بداند کد جدید را کجای پروژه بنویسد متوجه شود. به‌عبارتی، معمار باید مثل یک مترجم عمل کند.

یکی از نکات جالبی که جکی رید گفت این بود که خیلی از مشکلات معماری، ریشه در نگاه‌ های متفاوت دارد. مثلا تیم پشتیبانی به قابلیت ثبت ‌نام کاربر به‌عنوان فرم ورود اطلاعات نگاه می‌کند، ولی تیم امنیت به ‌عنوان ریسک نفوذ نگاه می‌کند. اگر معمار نتواند این اختلاف نگاه را مدیریت کند و به همه بگوید که هدف نهایی چیست، آنوقت طراحی عالی‌ ترین سیستم هم به ‌مرور زمان تبدیل به چیزی می‌شود که هیچ‌ کس از آن سر در نمی‌آورد.

اگر می‌خواهیم یک معمار خوب شویم، باید اول از همه ارتباطات و گوش دادن را یاد بگیریم. وقتی یک تصمیم معماری می‌گیریم، باید بتوانیم آن را به زبان خیلی ساده برای یک مدیر کسب‌ و کار توضیح بدهیم و همچنین بتوانیم آن را به شکل دقیق فنی برای تیم برنامه ‌نویسی تشریح کنیم.

سخنران: Sam Newman, Jacqui Read, Simon Rohrer

لینک: https://www.youtube.com/watch?v=Gp5KjP3tFJU

3.      Adaptive Architectures: Reimagining API Federation & Microservices Integration

با گسترش استفاده از معماری میکروسرویس، یکی از چالش‌های مهم تیم ‌های توسعه، برقراری ارتباط بین سرویس‌ های متعدد است. در بسیاری از پروژه ‌ها برای اتصال سرویس‌ ها، حجم زیادی از کد های واسط (Glue Code) نوشته می‌شود که وظیفه تبدیل داده ‌ها، فراخوانی APIها و هماهنگ ‌سازی سرویس‌ ها را بر عهده دارند. اگرچه این روش در ابتدا ساده به نظر می‌رسد، اما با بزرگ‌تر شدن سیستم، نگهداری این کد ها دشوار شده و کوچک‌ترین تغییر در یک سرویس می‌تواند باعث ایجاد تغییرات زنجیره ‌ای در بخش‌های مختلف سیستم شود.

این مشکل الزاما ناشی از معماری مایکروسرویس نیست، بلکه به شیوه‌ی طراحی ارتباط میان سرویس‌ها مربوط می‌شود. ایده‌ی اصلی این است که به جای نوشتن کد های زیاد برای اتصال سرویس ‌ها، باید مشخصات APIها مانند OpenAPI و gRPC را به عنوان بخش اصلی معماری در نظر گرفت. در این صورت، سیستم می‌تواند بسیاری از ارتباطات را به صورت خودکار مدیریت کند و وابستگی میان سرویس‌ ها کاهش یابد.

یکی از نکات جالب این ارائه معرفی زبان Taxi است. این زبان امکان اضافه کردن اطلاعات معنایی به APIها را فراهم می‌کند. در نتیجه، سیستم تنها نام فیلدها یا نوع داده‌ها را نمی‌شناسد، بلکه مفهوم واقعی آن‌ها را نیز درک می‌کند. به کمک این اطلاعات، موتور اجرای TaxiQL قادر است بدون نیاز به نوشتن حجم زیادی از کد، سرویس‌های مناسب را پیدا کرده و آن‌ها را برای پاسخ به یک درخواست با یکدیگر ترکیب کند.

به نظر من آینده‌ ی معماری نرم‌ افزار به سمت کاهش وابستگی به کد نویسی دستی حرکت می‌کند. در بسیاری از پروژه ‌ها، توسعه ‌دهندگان زمان زیادی را صرف نوشتن کدهایی می‌کنند که ارزش تجاری مستقیمی برای محصول ایجاد نمی‌کنند و تنها برای اتصال اجزای مختلف سیستم مورد استفاده قرار می‌گیرند. اگر بتوان این فرآیند را با استفاده از استانداردها و ابزارهای هوشمند خودکار کرد، علاوه بر کاهش هزینه توسعه، سرعت تغییرات نیز افزایش پیدا خواهد کرد.

موضوع مهم دیگری که Marty Pitt به آن اشاره می‌کند، مفهوم Adaptive Architecture یا معماری تطبیق‌پذیر است. در چنین معماری ‌ای، سیستم می‌تواند خود را با تغییرات محیط، نسخه‌های جدید APIها یا اضافه شدن سرویس ‌های تازه سازگار کند، بدون آنکه نیاز به بازنویسی گسترده کد وجود داشته باشد. این ویژگی برای سازمان‌هایی که ده‌ها یا صدها مایکروسرویس دارند، اهمیت بسیار زیادی دارد؛ زیرا در این مقیاس، مدیریت وابستگی‌ها به یکی از بزرگ‌ترین چالش‌های تیم ‌های فنی تبدیل می‌شود.

سخنران: Marty Pitt

لینک ویدئو: https://www.youtube.com/watch?v=VjaM0l55Inc

4.      Software Architecture: The Hard Parts

معمولا وقتی اسم معماری نرم فزار را میشنویم به انتخاب فناوری ‌ها یا طراحی بخش ‌های مختلف یک سیستم فکر می‌کنیم. اما این سخنرانی نشان می‌دهد که سخت ‌ترین قسمت معماری، انتخاب یک فناوری یا کشیدن چند نمودار نیست. به گفته او، بخش دشوار کار این است که بتوان بین چند راه‌حل مختلف تصمیم درستی گرفت؛ چون در بیشتر مواقع هیچ راه ‌حل کاملا درست یا کاملا اشتباهی وجود ندارد.

یکی از نکاتی که در این سخنرانی بیشتر از همه توجه من را جلب کرد، این بود که معمار نرم ‌افزار همیشه باید بین مزایا و معایب گزینه‌ های مختلف تعادل برقرار کند. مثلا ممکن است یک روش باعث شود برنامه سریع ‌تر اجرا شود، اما در عوض نگهداری آن سخت‌ تر شود. یا برعکس، ممکن است روشی وجود داشته باشد که توسعه آن ساده ‌تر باشد، اما هزینه بیشتری داشته باشد. بنابراین تصمیم گرفتن همیشه ساده نیست و باید شرایط پروژه را در نظر گرفت.

در ادامه توضیح می‌دهد که هیچ معماری ‌ای برای همه پروژه ‌ها مناسب نیست. چیزی که برای یک شرکت بزرگ جواب می‌دهد، ممکن است برای یک پروژه کوچک اصلاً انتخاب خوبی نباشد. به همین دلیل، معمار باید قبل از هر تصمیم، نیازهای واقعی پروژه را بشناسد و فقط به خاطر محبوب بودن یک فناوری یا روش، از آن استفاده نکند.

بخش دیگری از سخنرانی درباره تغییرات پروژه بود. تقریباً هیچ نرم ‌افزاری وجود ندارد که بعد از انتشار دیگر تغییری نکند. نیازهای کاربران عوض می‌شود، امکانات جدید اضافه می‌شود و حتی گاهی کل مسیر پروژه تغییر می‌کند. به همین دلیل معماری باید به گونه ‌ای باشد که این تغییرات را راحت‌ تر بپذیرد. اگر از همان ابتدا همه چیز بیش از حد پیچیده طراحی شود، بعدا ایجاد تغییرات زمان و هزینه زیادی خواهد داشت.

یکی دیگر از نکات جالب سخنرانی این بود که تصمیم‌ های معماری نباید فقط در ذهن یک نفر باقی بمانند و پیشنهاد می‌کند که دلیل انتخاب هر تصمیم ثبت شود تا اعضای تیم در آینده بدانند چرا آن تصمیم گرفته شده است. این کار باعث می‌شود اگر چند ماه یا چند سال بعد لازم باشد تغییری ایجاد شود، افراد راحت‌تر بتوانند وضعیت پروژه را درک کنند.

سخنران:  Neal Ford

لینک ویدئو: https://www.youtube.com/watch?v=x3Ay6yBoclo

5.      Democratising Software Architecture

این سخنرانی توضیح می‌دهد که معماری نرم‌ افزار دیگر نباید کار یک نفر باشد، بلکه باید توسط تمام اعضای تیم به اشتراک گذاشته شود. او با معرفی ایده‌ی Continuous Architecture نشان می‌دهد چگونه رویکردهای  Agile و DevOps معماری را به یک کار تیمی تبدیل کرده‌اند.

Woods  تاریخچه‌ ای از معماری نرم ‌افزار ارائه می‌دهد و می‌گوید در گذشته معمولاً یک معمار یا گروه کوچکی از متخصصان در ابتدا طراحی معماری را انجام می‌دادند و مستندات سنگین می‌ نوشتند. اما امروزه با آمدن  DevOps، Cloud  و توسعه اجایل و میکروسرویس‌ ها، چرخه‌ های انتشار سریع‌ تر شده و نیازها دائماً تغییر میکنند. بنابراین تصمیم‌ های معماری نباید همه در ابتدا گرفته شود؛ بلکه معماری باید هر چند وقت یک ‌بار بازنگری و اصلاح شود.

او می‌گوید امروزه تیم‌ های توسعه خودگردان و کوچک می‌توانند بسیاری از تصمیم‌ها را بگیرند، پس بهتر است معماری به عنوان مهارتی عمومی در تیم در نظر گرفته شود نه نقش یک نفر. در این رویکرد، اسناد معماری حجیم جای خود را به دیاگرام‌ های ساده و یاد داشت‌های سبک داده ‌اند و تیم‌ ها از ابزار های نظارتی برای فهم معماری پویا استفاده می‌کنند. به عبارت دیگر، معماری باید پیوسته کنار کد توسعه داده شود؛ یعنی هر اسپرینت یا در هر مرحله از توسعه، نگاهی دوباره به معماری داشته باشیم.

یکی از مفاهیم کلیدی این سخنرانی این بود که معماری یک shared commons است. همچنین تاکید می‌کند که این روش باعث می‌شود تیم‌ ها با هم بهتر کار کنند و پروژه‌ ها نتایج بهتری داشته باشند  این دیدگاه جدید نشان می‌دهد که چالش معماری امروز بیشتر در نحوه تصمیم‌گیری و تیم‌ بندی است تا در انتخاب فناوری‌های خاص. وقتی همه اعضای تیم در جریان معماری قرار می‌گیرند، می‌توانند سریع‌تر ویژگی‌های جدید اضافه کنند و بهتر به نیازهای مشتریان واکنش نشان دهند.

سخنران : Eoin Woods
لینک :  https://www.youtube.com/watch?v=nchRmYvUf2Y

اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است
#معماري_نرم_افزار_بهشتي #معماری_نرم افزار