مروری بر تعدادی سخرانی درباره‌ی معماری نرم‌افزار

1. https://youtu.be/j_WTlMq6VPs?si=b8F7HDbmTsgHtf-P

آقای Leo Mattos در گفتوگو با آقای Imran Khan درکنفرانس XConf 2021 NA درباره حکمرانی معماری سبک برای همه حتی نرم‌افزارهای عظیم صحبت نمودند که چگونه مراحل مختلف توسعه‌ی محصول و توپولوژی تیم‌ها بر نحوه ای که مدل معماری را تعریف می‌کنیم تاثیر گذار است.

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

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

عمران در رابطه با اینکه چه ویژگی‌های محصول نرم‌افزاری بر روی حکمرانی معماری تاثیر گذار است میگوید که اگر مدل عمر محصول نرم‌افزاری را مدل 3X Kent Beck در نظر بگیریم که در آن محصول دارای سه مرحله‌ی کاوش Explore و توسعه Expandو استخراج Extract در نظر بگیریم، باید برای هر مرحله یک معماری مناسب بر اساس هدف‌های کسب و کار و نیازمندی ها و توپولوژی تیم در نظر بگیریم.

در مراحل ابتدایی توسعه با ۱ تا ۵ تیم که نیاز به ورود سریع به بازار رقابتی داشته ولی از تصمیماتی که میگیریم مطمئن نیستیم در عین حال قدرت تغییر بالایی داشته و باید مزایا و معایب هر تصمیم را سبک سنگین نموده و تصمیمات برگشت پذیری گرفته و آنان را مستند کنیم. برای این مرحله می‌توان از Tech radar استفاده کنیم تا بین مشکلات و تکنولوژی‌های راه حل آن‌ها ارتباط برقرار کنیم.

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

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

2. https://youtu.be/j6ow-UemzBc?si=pDzTlgnnmOFc4424

آقای Micheal Bryzek در کنفرانس QCon ۲۰۱۸ نیویورک درباره‌ی نحوه‌ی درست طراحی معماری میکروسرویس سخرانی خود را با طرح مثالی از کارفرمای خود که از او تغییری در یک لینک URL خواسته بود و برخلاف تصور کارفرما این تغییر به ظاهر ساده نیازمند چند هفته زمان بود شروع کرد. تغییرات ممکن است زمانبر باشند زیرا سرویس‌های زیادی وحود دارند که مدت زمان زیادی است به‌هنگام سازی نشده و وابستگی‌ها و کتابخانه‌های آن‌ها نیز نیاز به تغییرات خواهند داشت.

مایکل یکی از مشخصه‌های یک معماری عالی را این می‌داند که احتمالا تا سال‌ها مشکلی بابت تغییرات نخواهید داشت.

او سخرانی خود را با تعدادی باور اشتباه درباره‌ی معماری نرم‌افزار ادامه می‌دهد:

۱ – معماری میکروسرویس به تیم‌ها اجازه می‌دهد تا بهترین زبان برنامه نویسی برای وظایف خود را استفاده کنند:

اما در حقیقت انتخاب زبان جدید کاری بسیار هزینه بر بوده و باید بر اساس سرمایه‌ها و سایز تیم این موضوع انتخاب شود.

۲ – گزارش و لاگ‌ّهای وقایع باید به عنوان منبع حقایق در نظر گرفته شوند:

اما در حقیقت هرچند لاگ‌ها بسیار مهم هستند اما می‌توان از پایگاه‌داده‌ها نیز استفاده نمود.

۳ – هر توسعه‌ دهنده نباید روی نگه‌داری بیش از ۳ سرویس کار کند:

حقیقت آنست که با وجود ابزارهای خودکارسازی هر توسعه دهنده می‌تواند روی نگه داری ۵ سرویس کار کرده و تنها درصدی از زمان خود را به این کار اختصاص دهد.

و اما نکات توسعه‌ی میکروسرویس به نحوه مناسب:

در API ها از کلماتی استفاده کنید که در پایگاه‌داده نیز استفاده شده است.

موارد یکتا مانند نام کاربری ایمیلی را در سراسر پروژه ردیابی کنید.

مهم نیست که API ها توسط یک یا چند تیم توسعه داده شوند، یکپارچگی و سازگاری آن‌ها با هم مهم است.

با کمک ابزارهایی مانند API Builder نقاط احتمالی شکست در زمان تغییرات API ها را در فاز طراحی مشخص کنید.

تست پذیری میکروسوریس ها نیز باید قبل از توسعه‌ی آن‌ها مورد بررسی قرار گیرد.

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

برای خودکارسازی فرآیندها هزینه کنیم.

هر میکروسرویسی باید پایگاه‌داده‌ی مخصوص و خصوصی خود را داشته باشد و دیگر میکروسرویس‌ها تنها اجازه‌ی استفاده از واسط کاربری (API + Events) آن را خواهند داشت.

در صورت استفاده از تعداد زیادی میکروسرویس حتما باید از فرآیند CI/CD استفاده کنیم.

تمامی تغییرات باید به صورت جدولی در مستند ذخیره شوند یعنی هم چیزی که بوده، هم چیزی که هست و هم چیزی که قرار است بشود.

این Eventهای جدید باید در یک پایگاه داده محلی ذخیره و دسته بندی شوند تا پاک کردن آن‌ها راحت باشد. همچنین ایونت‌ّایی که میرسند باید در یک صف قرار گیرند. این ایونت های داخل صف باید در برهع زمان‌های کوچک (نه در لحظه) مانند هر ۲۵۰ میلی ثانیه پردازش شوند.

مشکلات و شکست‌ها نیز باید به صورت محلی ذخیره شوند.

وابستگی‌های سرویس‌ها را باید همیشه به روز نگه داریم، خصوصا وابستگی‌های امنیتی را حتی اگر هزینه بیشتری برای ما داشته باشد.

3. Five Things Every Developer Should Know about Software Architecture • Simon Brown • GOTO 2020 (youtube.com)

آقایSimon Brown در کنفرانس 2020 goto درباره‌ی ۵ چیزی که هر توسعه‌دهنده باید درباره‌ی معماری نرم‌افزار بداند می‌گوید:

۱ – معماری نرم‌افزار یک طراحی یکباره ، کامل و برای همیشه نیست.

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

او این نظر را با نقل قولی از آقای گردی بوچ ادامه می‌دهد:”معماری نرم‌افزار تصمیمات کلانی است که گرفته می‌شوند و معیار کلان بودن آن‌ها بر اساس هزینه‌های تغییرات مشخص می‌شوند” پس تنها تصمیمات لازم و کافی گرفته شده و درباره چیزهایی که مطمئن نیستیم کاری نمیکنیم.

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

۲ – تمام تیم‌های نرم‌افزاری باید از معماری نرم‌افزار آگاه بوده و آن را در نظر بگیرند.

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

۳- نقش معماری نرم‌افزار هم کدنوشتن و هم هدایت و همکاری تیم است.

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

۴- نیازی به استفاده از UML نیست.

آقای براون این نمودارها را بسیار وقت گیر و پیچیده می‌داند و در عین حال ممکن است به قدر کافی کمک کننده نباشند. او روش C4 را برای مستندسازی پیشنهاد می‌کند.

۵- یک معماری نرم‌افزار خوب قابلیت چابک بودن را به ما اضافه می‌کند.

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

4. The Problem with Microservices • Dave Farley • GOTO 2021 (youtube.com)

آقای Dave Farley در کنفرانس goto 2021 درباره‌ی مشکل میکروسرویس‌ها سخرانی کرده و علیرغم محبوبیت بسیار، درک نکردن درست آن‌ها را خطری برای شرکت می‌داند.

به عقیده‌ی او میکروسرویس‌ها، سرویس‌های کوچک نبوده و یک معماری سیستم توزیع شده است که همین امر آن‌ها را پیچیده تر و مستعد مشکلات فراوان می‌کند. میکروسرویس‌ها، rest API های ساده نیستند، هرچند فناوری rest میتواند در میکروسرویس‌ها مورد استفاده قرار گیرد.

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

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

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

5. The Role of QA in Agile Software • Dave Farley • GOTO 2022 (youtube.com)

آقای Dave Farley در کنفرانس goto 2022 نیز درباره‌ی نقش تضمین کیفیت در فرآیند توسعه‌ی چابک نرم‌افزار سخنرانی داشته که خلاصه‌ی آن را میتوانید بخوانید:

استفاده از روش‌های توسعه‌ی چابک و CI/CD مزایای بسیاری مانند کارایی و کیفیت بالا را به دنبال داشته و تیم‌ها بازخورد خوبی از اعمال خود میگیرند با استفاده از این روش، نرم‌افزار همیشه قابل انتشار است. اما این نوع توسعه نقش‌های افراد و باور‌های ما درباره‌ی این نقش‌ها را دگرگون می‌سازد یک از این نقش‌ها تضمین کیفیت است.

افراد با نقش تضمین کیفیت (Quality Assurance) یا QA در این فرآیند دیگر تنها کنترل کننده‌ی خروجی نهایی و انتشار نرم‌افزار نیست زیرا در صورت که QA کیفیت یک محصول را مردود اعلام کند، دیگر انتشار مداوم و چرخه‌ی فرآیند CI/CD معنی نخواهد داشت.

برای اینکه یک نرم‌افزار بعد از تغییرات منتشر شود دو هدف در مورد آن باید محقق شوند:

۱ – آیا نرم‌افزار کاری که به علت آن تغییر کرده را انجام می‌دهد؟

۲ – آیا نرم‌افزار کار‌هایی را که قبل از تغییر انجام می‌داده و هنوز هم باید انجام بدهد را انجام می‌دهد؟

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

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

آقای فارلی جداکردن تیم QA از توسعه‌دهنده‌ها را نیز مضر و باعث ناسازگاری دانش در مورد محصول می‌داند.
--------------------------------------------------------------------------------------------------------------------------------------

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