چگونه چابک باشیم ولی اصول یک معماری خوب نرم افزاری را هم حفظ کنیم؟

https://unsplash.com/روز های اولی که با اصول چابک(Agile), از طریق XP آشنا شده بودم یادم نمیره. دچاری تعارض بدی بودم از یک طرف میدیدم متدولوژی های RUP که و در اون نقش معمار و اصول معماری با فرایند ها و دیسیپلین های سخت از پیش تعریف شده نهادینه شده بود و شفاف بود. درحال از بین رفتنه, جای خودشو داره به یک اصولی می ده که بنظر می رسد پایبندی مشخصی به معماری و کیفیت نداره بلکه فقط میخواد زودتر یک نرم افزار بسازه و بدست مشتری برسونه حتی لعنتی پایبند به مستندسازی هم نیست.بنابراین هی با خودم می گفتم این هم یه چند روزی هست و تب فضای نرم افزاره ولی چند سال بعد که مشکلاتش بیرون زد ازبین میره.زمان گذشت دیدم سروکله اسکرام پیدا شد اونم میگه هر دو هفته یا سه هفته باید یه فیچر به کاربر داد.و سازمانها یکی بعد از دیگری در حال های پیاده سازی اونن با خودم گفت دیگه انکار بسه مثل اینکه این تغییر بیشتر از حذف مستندات ، دو هفته ای کار کردن و کاغذی های رنگی قشنگه.یادم نمیره رفته بودم برای مصاحبه توی یک شرکت وقتی کانبان برد اونجا رو دیدم توی دلم گفتماوه اوه .. اینجا هم از این قرتی بازیا داره.حالا باید اقرار کنم بعد از کار توی چندین شرکت و کار با دوستانی خوبی که مفاهیم چابکی رو خوب درک کرده بودند به روشنی میگمبزرگترین تحول در تولید نرم افزار توی این سالهای اخیر همین تفکر چابک است.شاید شما هم مثل من دچار این تعارض شده باشید من توی این متن سعی دارم راجب تحول فکری خودم بگم و راهی که رفتم.رویکرد چابک با در مرکز قرار دادن مشتری و تغییر رویکرد, به ایجاد ارزش برای مشتری انگار جایی برای تفکر معماری و اصول اولیه تولید نرم افزار ارزان(high internal quality) و با کیفیت قائل نیست.Martin Fowler“High internal quality leads to faster delivery of new features, because there is less cruft to get in the way”--Martin Fowlerتازه اوضاع بدتر میشه وقتی که می فهمید برای مشتری اصول نرم افزار و ابزار و استاندارها همگی از جنس کیفیت داخلی بوده نه قابل درکه و نه قابل دیدن پس ارزشمند محسوب نمیشه.از اون بدتر میشه وقتی که رویکرد سازمان محصول گرا شده و از شما خودمختاری می خواهند.تعارض بدیه از یک طرف همه شما رو به عنوان معمار یا مدیرفنی، وقتی سیستم باگ داره یا دچار Crash میشه خلاصه بگم بدهی های فنی بیرون میزنه مسئول میدونن از طرف دیگر جایی برای ایجاد یک زیرساخت خوب قائل نیستند.معماران نرم افزار سالهاست که یاد گرفته اند چگونه اصول یک معماری خوب از همون روز اول و با صرف وقت و ایجاد فریم ورک ها و پیاده سازی استاندارد های سختگیرانه و انتخاب ابزارها مناسب و … نهادینه کنن.حالا فرض کنید چنین تفکر میخواد کنار تفکر چابک قرار بگیره رسما تعارضهاین تعارض شاید دردناک باشه و سرچشمه تحولات معماری بعد از ایجاد موج چابک در سالهای اخیر است.برای حل این تعارض بهتر است پناه ببریم به همون به پنج اصل کلیدی از ۱۲ اصل چابک با رویکرد معماری"توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود"پس در گام نخست چابک با کیفیت و طراحی خوب مشکلی ندارد بلکه اونو باعث افزایش چابکی می داند."بهترین معماری ها , نیازمندی ها و طراحی ها از تیم های خود سازمانده پدید آور می شود"گام بعدی تیم های "خود سامانده" اساس ایجاد یک معماری خوبه نه ساختارهای سخت از پیش تعریف شده و تمرکز گرا"پروژه ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی کنید و به آنها اعتماد کنید تا کارها را انجام دهند"خودمختاری نه تنها منجر به خودساماندهی میشه بلکه انگیزه راهم بالا می برد."استقبال از تغییر نیازمندی ها، حتی در اواخر فرآیند توسعه. فرآیند های چابک، تغییر را در جهت مزیتِ رقابتی مشتری مهار میکنند"استقبال از تغییر به جای مقابله با آن"بالاترین اولویت ما جلب رضایت مشتری با تحویل زود و مداوم نرم افزاری ارزشمند"معماری نرم افزار همگرا با چابک باید دارای چندین خصوصیاتی باشد:از تمرکز گرایی پرهیز کند تا خود ساماندهی به وجود بیاید.خودمختاری را پشتیبانی کند تا هم انگیزها را بالا ببرد و هم کمک کند به خود ساماندهیهزینه تغییرات را به شدت پایین بیاورد.امکان تحویل خرد خرد داشته باشد تا تداوم ایجاد کند.Werner Vogels Amazon CTO 2006“The first and foremost lesson is a meta-lesson: If applied, strict service orientation is an excellent technique to achieve isolation; you come to a level of ownership and control that was not seen before.”-- Werner Vogels Amazon CTO 2006این ها اساس شکل گیری موج بعدی چابک یعنی معماری میکروسرویس است.سرویس گراست.نرم افزار رابه واحد های سازنده کوچک شکسته و آن ها را در قالب سرویس های مستقل از هم توسعه می دهد.به صورت ذاتی توزیع شده است.با پرهیز از هرگونه تمرکز گرایی توزیع شدگی را نهادینه دارد.از خود مختاری حمایت می کند.مایکروسرویس با کوچک کردن سرویس ها و سست کردن ارتباط میان آنها و حتی غیرمتمرکز کردن مدیریت داده ها (Database های جدا از هم) خودمختاری را تقویت می کند.تغییر در آن آسان تراست.هر سرویس Base Code خود را دارد و با ایجاد لایه انتزاعی خود از نشت کردن تغییرات به سایر سرویس ها جلوگیری می کند.تحویل سیال با به حداقل رساندن هماهنگی جهت انتشاراجازه می دهد سرویس ها جدا از هم و به طوری موازی توسعه و بهبود داده شوند.استقلال سرویس ها از هم سبب می شود دیگر نیاز به هماهنگی جهت انتشار به حداقل خود برسد. اینجاست که شما دیگر یک جریان سیال و خرد خرد و پر تکرار از تحویل به مشتری دارید.برگرفته از گارتنرمساله همچنان باقی است؟ تکلیف معماری و کیفیت توی این فرهنگ جدید چیه؟شما به عنوان معمار نرم افزار یا مدیر فنی از هر سبکی که استفاده می کنید:چه به عنوان معمار و مدیر فنی تمام تصمیمات مهم را می گیرد.تا مطمئن شود کلیه سیستم از یک یکپارچگی لازم و مفهومی برخوردار است و معتقدید که اعضای تیم از مهارت های لازم برای انجام این تصمیم برخوردار نیستند.و یا سعی دارید همواره از آنچه که در پروژه می گذرد با خبر باشید و به دنبال موضوعات مهم بوده تا قبل از اینکه تبدیل به چالش بزرگی شود با تعامل زیاد با تیم ها با آن مقابله کنید.باید پارادایم ذهنی خود را تغییر داده و بدونید در فضای چابکدیگر اصول معماری و کیفیت مساله فقط یه معمار یا مدیر فنی نیست(متمرکز و مرکز گرا نیست) بلکه مثل خود مایکروسرویس توزیع شده است یعنی تیم های توسعه دهند سرویس ها هم باید این دغدغه را داشته و مشارکت کنند.وظیفه شما ایجاد ساختارها و فرایندها و تمهیداتی است که خودمختاری را به حداکثر برساند.حال چگونه ساختارها و فرایندها و تمهیداتی ایجاد کنیم که خودمختاری را به حداکثر برساند؟اگر توجه کنید معماری میکروسرویس دارای دو وجه بیرونی و درونی است.برگرفته از گارتنروظیفه شما ,ایجاد همسویی (Alignment)است و شما می توانید با تمرکز بر روی وجه بیرونی و با مشارکت تیم ها همسویی لازم را ایجاد نمایید.نحوه ارتباط و ارکستریشن سرویس هااستراتژی برای Versioning سرویس هاطراحی زیر ساخت برای Scale Outمجازی سازی کردن دسترسی به سرویس ها از دنیای خارجامنیتمانیتورینگ و مدیریت یکپارچه log هاتعیین واحد استقرارزمانی که مشخصات این وجه بیرونی مشخص شد آنگاه خودمختاری قابل اعطا به تیم های تولید سرویس می باشد.البته یادتان نرود همین اصول معماری بیرونی هم باید قابل تغییر توسط تیم ها باشد شما و تیم ها باید مکانیسمی برای تحول در صورت نیاز داشته باشید. نقش شما صرفا از ایجاد رویکردهایی برای Alignment است.حال با وجهه درونی چکار باید کرد؟ آیا خودمختاری در این حوزه منجر به از دست رفتن کیفیت نمیشه؟اینجا نقش شما چیه؟بهتره در اینجا از دو فرهنگ سازمانهای چابک کمک بگیرید. "Fast Failed" و "Data Driven"ابتدا اجازه بدید بجای اعمال استانداردهای از پیش نوشته شده و اعلان آن به تیم ها, خود تیم ها به صورت خودمختار دست به انتخاب ابزارها و استانداردها و … زده و شما با ایجاد و تعریف معیارهای کیفی مثل throughput , Load و … و پیاده سازی آن از طریق گیت های تست و فراهم کردن بستری CI/CD آنها را زودتر به چالش بکشید وبا جمع آوری اطلاعات از طریق سیستم های مانیتورینگ و Log تیم ها را ترغیب به برگزاری جلسات Postmortem کرده و برای اعضای تیم فضای یادگیری ایجاد نمایید.تا اقدام به بهبود نمایند.زمانی که استانداردها , ابزارها و حتی Library ها درست بدست آمد و یادگیری انجام شد اجازه بدهید این استاندارد ها خود به خود بین تیم های انتشار یابد و از یکدیگر بیاموزند.به طور مثالروش گرده افشانی در شرکت اسپاتی فاینتفلیکس اجازه می دهد کدهای مشترک و تست شده در قالب کدهای متن باز در اختیار سایر تیم ها قرار گرفته و آنها را تشویق می کند از این کدها استفاده کنند. ولی در صورت لزوم مسیر را باز می کند تا تیم ها بتوانند مسائل را به روش متفاوتی حل کنند.باید گفت درسته فضای تولید نرم افزار با رویکرد چابک دچار تغییر شده ولی دیگر نمی توان با پارادایم های قبلی با آن همراه شد.وظیفه شما به حداکثر رسانی تغییرپذیری است و این با افزایش خود مختاری و جدا کردن دغدغه ها در قالب سرویس های کوچک قابل بدست آمدن است.در این مقاله سعی شد، در رابطه با تحول چابک بر روی معماری نرم افزار و ایجاد مایکروسرویس صحبت شود در آینده سعی می کنم در رابطه با موج های بعدی این تحول بیشتر بنویسم.به نظر شما خودمختاری (Autonomy)که اساس این نوع معماریه چطوری منجر به ایجاد نتایج شگفت انگیز میشه؟؟