منظور از "معماری چابک" چیست؟

[Rohalah Delpak]

"معماری چابک "، به طور ساده، معماریست که اصولی در تهیه آن لحاظ شده باشد. مثلا اصول SOLID یا PoEA در تدوین آن مورد توجه بوده باشند. معماریی هم داریم که اینگونه نیست و به تدریج، فرآیند توسعه را برای توسعه دهندگان به کابوس تبدیل می کند. اینها موضوعات جدیدی نیستند و قدمت چند ده ساله دارند. در اصول بیانیه چابک هم توجه داده شده است به این مفاهیم، مثلا:

Continuous attention to technical excellence and good design enhances agility.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Working software is the primary measure of progress.

agilemanifesto.org/principles.html

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

همین موضوع در بند اول هم تاکید شده است. Good Design به "تقویت" و نه "تضمین" اجایلیتی می انجامد.

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

یا مثلا تیاز به تغییر سریع و بدون درد و خون ریزی پایگاه داده. می شود بدون ORM به این هدف رسید؟ به هر حال از این دست مسائل فراوانند. به خصوص در بحثهایScalability .

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

• Welcome changing requirements, even late in development.

 

اگر توسعه به سبک چابک را برگزیده اید، لازم است از چابکی معماری مورد استفاده تان هم مطمئن شوید. در آینده بیشتر در مورد SOLID و PoEA خواهم گفت.