خلاصهای از ۵ ویدیو مرتبط با معماری نرمافزار از کنفرانسهای GOTO
برداشت و گردآوری توسط امیرحسین میرزایی
عنوان سخنرانی: Residues: Time, Change & Uncertainty in Software Architecture
سخنران: بری اورایلی
پیوند ویدیو: https://www.youtube.com/watch?v=D8qQUHrksrE
خلاصه و برداشت من از این سخنرانی:
بری اورایلی در این ارائه دیدگاهی کاملا ساختارشکنانه برای مدیریت عدم قطعیت در سیستمهای نرم افزاری معرفی میکند [00:17]. برای ارائه یک تصویر کامل از مباحث مطرح شده، نکات اصلی را به صورت بخش به بخش بررسی میکنم تا هیچ جزئیاتی از این معماری نوین از قلم نیفتد.
سخنران در ابتدا تاریخچه مواجهه مهندسان با پیچیدگی را به سه دوره تقسیم میکند: دوره اول که تلاش میشد پیچیدگیها با منطق ریاضی مهار شوند [03:16]، دوره دوم که راه حل را در ایجاد ساختارهای بلوکبندی شده میدید [04:19] و دوره سوم که رویکردهای چابک برای انطباق با تغییرات مداوم شکل گرفتند [06:06]. او توضیح میدهد که محیط اطراف نرم افزار پر از هرج و مرج است، اما خود نرم افزار ساختاری خشک و مکانیکی دارد که در این محیط به راحتی در هم میشکند [07:21].
برای حل این مشکل، اورایلی پیشنهاد میدهد که از علوم پیچیدگی الهام بگیریم. او با یک مثال هندسی نشان میدهد که گاهی به جای فرمولهای دقیق، میتوان با پرتاب تصادفی دارت به مساحت یک شکل نامنظم پی برد [12:35]. در طراحی ساختار نرم افزار نیز به جای اتکای صرف به پیشبینی نیازمندیها، باید سناریوها و فشارهای کاملا تصادفی و دور از ذهن را به سیستم وارد کنیم تا واکنش آن سنجیده شود.
در بخش علمیتر ارائه، او به شبکههایی از گرههای مرتبط اشاره میکند؛ سیستمهایی که بینهایت حالت ممکن دارند اما در نهایت فقط به سمت تعداد محدودی حالت پایدار که جاذب نامیده میشوند، میل میکنند [17:28]. اورایلی معتقد است طراحی ما نباید برای یک مسیر خوشبینانه انجام شود، بلکه باید برای زنده ماندن در این نقطههای جاذب آماده باشد [22:00].
هسته اصلی این سخنرانی، نظریه پسماند است. وقتی سیستم را با یک رویداد غیرمنتظره تحت فشار قرار میدهیم، ساختار اولیه میشکند. پسماند در واقع همان بخش باقیمانده و تغییر کوچکی است که اگر در سیستم وجود داشت، باعث نجات آن میشد [23:33]. با تکرار این شبیهسازیهای تصادفی، ما مجموعهای از پسماندها را جمعآوری و با هم ترکیب میکنیم.
برداشت من: با توجه به اینکه حوزه تز ارشد بنده هم در حیطه سیستمهای خود تطبیق بود و ارتباط آن با معماری یک نرمافزار جذاب است، آنچه این رویکرد در ویدئو را برای من متمایز میکند، تغییر نگاه از طراحی صرف به آموزش معماری نرمافزار است [43:05]. این دیدگاه برای معماری سیستمهای خودتطبیق که نیازمند تضمین ایمنی در زمان اجرا هستند، بسیار کاربردی است. وقتی سیستم با قرار گرفتن در محیطهای شبیهسازی شده و تحت فشارهای تصادفی مقاوم میشود، میتواند در برابر خطراتی که حتی در فاز جمعآوری نیازمندیها دیده نشده بودند نیز دوام بیاورد [34:29]. در نهایت، هدف یک طراح سیستم دیگر رسیدن به صحت کامل برنامهنویسی نیست، بلکه رساندن سیستم به مرز تابآوری است؛ جایی که سیستم هم انسجام خود را حفظ میکند و هم توانایی تطبیق با رویدادهای ناشناخته را دارد [38:23].
عنوان سخنرانی: Architecture for Flow
سخنران: سوزان کایزر در گفتگو با جیمز لوئیس
پیوند ویدیو: https://www.youtube.com/watch?v=NwtE82Wzs_U
خلاصه و برداشت من از این گفتگو:
این ویدیو مصاحبهای بسیار آموزنده با سوزان کایزر درباره کتاب جدیدش با موضوع معماری نرم افزار برای ایجاد جریان کاری روان است. در ابتدای گفتگو سوزان توضیح میدهد که چگونه تجربیاتش به عنوان مدیر ارشد فناوری در شرکتهای نوپا باعث شد تا با چالشهای سیستمهای نرم افزاری یکپارچه و پیچیده روبرو شود [02:14]. او برای حل این مشکلات به سراغ مفاهیمی مانند طراحی مبتنی بر دامنه رفت تا بتواند سیستمها را به بخشهای مستقل و کارآمدتری تقسیم کند.
برداشت اصلی من از این سخنرانی این است که برای ساختن یک محصول موفق، نمیتوانیم فقط به یک جنبه توجه کنیم. سوزان به زیبایی سه مفهوم اساسی را با هم ترکیب میکند: استفاده از نقشههای واردلی برای درک زنجیره ارزش و نیازهای تجاری، طراحی مبتنی بر دامنه برای معماری نرم افزار، و روشهای چیدمان تیم برای سازماندهی ارتباطات انسانی [04:20]. او باور دارد که ساختار ارتباطی سازمان مستقیما روی معماری نرم افزار تاثیر میگذارد و ترکیب این سه دیدگاه میتواند راهگشای بسیاری از مشکلات توسعه محصولات فناوری باشد.
بخش جالب دیگری که توجه مرا جلب کرد، تاکید او بر شناسایی گلوگاهها در سیستم است. او توضیح میدهد که اگر در یک سازمان فقط بخش کوچکی را بهینه کنیم و به موانع اصلی جریان کار توجه نکنیم، تمام تلاشهایمان بیفایده خواهد بود و کارها پشت تیمی که بیشترین محدودیت را دارد تلنبار میشود [08:55]. همچنین او درباره پویایی پنهان بین تیمها صحبت میکند و نشان میدهد که گاهی تیمها به جای ارتباط مستقیم با یکدیگر، تصمیم میگیرند کارهای موازی و تکراری انجام دهند که این موضوعات حتما باید شفاف شوند [12:01].
سوزان در کتاب خود یک بوم یا تابلوی راهنمای کاربردی معرفی کرده است که به تیمها کمک میکند وضعیت فعلی خود را ارزیابی کنند، موانع را بشناسند و آینده مطلوب خود را طراحی کنند [20:50]. نکته بسیار مهم این است که او پیشنهاد میدهد تصمیمگیری درباره ساختار آینده بر عهده خود اعضای تیمها باشد تا احساس مالکیت و مسئولیتپذیری بیشتری داشته باشند [25:38].
در نهایت مهمترین پیام او در پایان مصاحبه این است که پیش از درگیر شدن با پیدا کردن راه حلها، باید زمان کافی را برای شناخت دقیق مشکل و نیازهای کاربر صرف کنیم [27:30]. فرقی نمیکند کاربر ما مشتری نهایی در بیرون از سازمان باشد یا تیمهای داخلی شرکت که از خدمات یکدیگر استفاده میکنند، اگر محصول ما نتواند نیاز آنها را برای انجام راحتتر کارشان برطرف کند هیچ ارزشی نخواهد داشت. این رویکرد همهجانبه میتواند برای هر شرکتی که به دنبال رشد و بهبود مداوم است، بسیار الهامبخش و راهگشا باشد.
عنوان سخنرانی: Expert Talk: DevOps & Software Architecture
سخنران: سایمون براون، دیو فارلی و هانس لوته
پیوند ویدیو: https://www.youtube.com/watch?v=Qv92qaIGbDg
خلاصه و برداشت من از این سخنرانی:
این ویدیو یک گفتگوی بسیار جذاب و عمیق میان سه متخصص برجسته در زمینه مهندسی و معماری نرم افزار است. در ابتدای گفتگو، سایمون و دیو به این موضوع اشاره میکنند که در یک دهه گذشته، رویههای توسعه و عملیات همراه با تحویل مداوم، بزرگترین و مثبتترین تغییرات را در دنیای ساخت نرم افزار ایجاد کردهاند [01:13]. این رویهها به تیمها اجازه میدهند تا با سرعت بیشتر و با رویکردی مهندسیتر محصولات خود را به دست کاربر نهایی برسانند.
یکی از نکات بسیار مهمی که در این گفتگو مطرح میشود، سوءبرداشت از روشهای توسعه چابک است. بسیاری از برنامهنویسان تصور میکنند چابک بودن به معنای کنار گذاشتن کامل طراحی اولیه است. اما دیو و سایمون تاکید میکنند که شما برای شروع حتما به یک مدل و طراحی اولیه نیاز دارید، با این تفاوت که باید بپذیرید این مدل قطعا ایرادهایی دارد و در طول مسیر تغییر خواهد کرد [05:42]. داشتن یک معماری خوب به شما کمک میکند تا پیچیدگیها را مدیریت کنید و هنگام بروز خطا، بتوانید بدون تخریب کل ساختار نرم افزار، تغییرات لازم را اعمال نمایید [07:42].
بخش جذاب دیگر این گفتگو به موضوع خدمات مستقل نرم افزاری یا همان سرویسهای خرد اختصاص دارد. متخصصان حاضر در این نشست معتقدند که بیشتر شرکتها این نوع معماری را به اشتباه پیادهسازی میکنند و باعث کندی و پیچیدگی بیدلیل کارهایشان میشوند [09:19]. پیشنهاد آنها برای اکثر تیمها، شروع کار با یک ساختار یکپارچه اما کاملا بخشبندی شده است [10:38]. وقتی مرزهای برنامه به درستی در یک ساختار یکپارچه مشخص شده باشند، در صورت نیاز در آینده به راحتی میتوان آنها را به خدمات کاملا مستقل تبدیل کرد تا از پیچیدگیهای غیرضروری جلوگیری شود.
همچنین، دیو فارلی به مفهوم تحویل مداوم اشاره میکند و توضیح میدهد که این مفهوم صرفا به معنای انتشار مداوم نرم افزار نیست، بلکه به این معناست که نرم افزار شما باید همیشه و در هر لحظه در وضعیتی باشد که قابلیت انتشار داشته باشد [25:55]. این کار نیازمند خودکارسازی فرآیندها، حذف کارهای تکراری و بالا بردن کیفیت معماری است. در نهایت، یکی از آموزندهترین بخشهای این صحبتها، مقایسه نرم افزار با مهندسی یک ساختمان است. برخلاف ساختمانسازی که در آن طراحی کامل پیش از شروع کار ضروری است، دنیای نرم افزار محیطی برای کشف و یادگیری است زیرا هزینه تولید و آزمایش در محیط واقعی تقریبا صفر است [36:01]. بهترین نصیحتی که دیو در پایان ارائه میدهد این است که از ابتدا فرض کنید قرار است همه چیز خراب شود؛ با این دیدگاه میتوانید معماری پایدارتر و انعطافپذیرتری طراحی کنید و هنگام بروز بحران در برنامه، درسهای بسیار ارزشمندی بیاموزید [37:48].
عنوان سخنرانی: SW Design, Architecture & Clarity at Scale
سخنران: سم نیومن، جکی رید و سایمون روهرر پیوند
ویدیو: https://www.youtube.com/watch?v=t67oWHa00iE
خلاصه و برداشت من از این سخنرانی:
این ویدیو یک میزگرد بسیار آموزنده درباره جایگاه طراحی و معماری در پروژههای بزرگ نرم افزاری است. در ابتدای نشست جکی رید به زیبایی توضیح میدهد که طراحی نرم افزار فقط محدود به لایه رابط کاربری یا نوشتن کدهای پایه نیست، بلکه یک جریان پیوسته است که از نیازهای تجاری و کلان شروع میشود و تا پایینترین لایههای مهندسی امتداد مییابد [03:07].
یکی از مهمترین مباحث مطرح شده در این گفتگو اهمیت ثبت مستندات تصمیمگیری معماری است. سخنرانان تاکید میکنند که دلیل اصلی ثبت این مستندات، نوشتن چرایی یک تصمیم است تا در آینده اگر شرایط تغییر کرد، تیم بداند که آیا میتواند آن تصمیم را لغو کند یا خیر [08:15]. برای طراحی ساختارهای پیچیده که در آنها سیستمها باید بتوانند به صورت خودکار با عدم قطعیتها تطبیق پیدا کنند و در لحظه تصمیمات ایمن بگیرند، داشتن یک تاریخچه دقیق از تصمیمات طراحی سطح بالا به شدت ضروری است. این مستندات به ما کمک میکنند تا روند تکامل معماری را ردیابی کنیم. همچنین اشاره شد که این طراحیها نباید به عنوان یک قانون تغییرناپذیر از بالا به پایین دیکته شوند، بلکه باید زمینهای برای گفتگو و همفکری میان تمام اعضای درگیر در پروژه فراهم کنند [10:06].
بخش جذاب دیگر نشست بحث درباره استانداردسازی بود. سایمون روهرر معتقد است که ما نباید بیش از حد روی یکسانسازی همه چیز پافشاری کنیم. هدف معماری این است که پیچیدگیها و تصمیمات تکراری را از دوش توسعهدهنده بردارد تا او بتواند تمام تمرکز خود را روی حل مشکلات اصلی تجاری و فنی بگذارد [33:14]. این دیدگاه برای توسعه و ارزیابی معماریهای نرم افزاری که نیاز به پیادهسازی الگوریتمهای یادگیری پیچیده و آزمایش در محیطهای شبیهسازی دارند بسیار راهگشا است، زیرا مشخص میکند کدام بخشهای زیرساخت باید یکپارچه و ثابت بمانند و در کدام بخشها دست توسعهدهنده برای آزمون و خطا باز است.
در نهایت موضوع ایجاد حلقههای بازخورد در معماری سیستم مطرح شد. معماری نرم افزار نمیتواند یک مسیر یکطرفه باشد. برای اینکه سیستمهای پویا و مقیاسپذیر به درستی کار کنند، نیازمند مشاهده و بررسی مداوم رفتار سیستم در محیط اجرا هستیم [43:01]. دریافت بازخورد از لایههای پایینتر مهندسی و مشاهده نحوه عملکرد معماری در عمل، به ما اجازه میدهد تا طراحی سطح بالا را به صورت مداوم اصلاح کنیم؛ رویکردی که دقیقا اساس کار سیستمهای پیشرفته و خودتطبیق امروزی را تشکیل میدهد.
عنوان سخنرانی: Master Software Architecture: From Simplicity to Complexity
سخنران: ماچی امجی ینژیوسکی
پیوند ویدیو: https://www.youtube.com/watch?v=ZCrCqbblXjk
خلاصه و برداشت دقیق من از این سخنرانی:
این ویدیو ارائه بسیار کاربردی و آموزندهای درباره مسیر تکامل یک نرم افزار و پرهیز از تلههای رایج در طراحی ساختار آن است. سخنران بحث خود را با این واقعیت آغاز میکند که ساخت معماری دشوار است اما تغییر آن در آینده بسیار دشوارتر خواهد بود [00:33]. برای ارائه یک تصویر کامل، مباحث مطرح شده را بخش به بخش بررسی میکنم تا ساختار این معماری تکاملی به روشنی مشخص شود.
سخنران در ابتدا هشدار میدهد که توسعهدهندگان نباید گرفتار تله فناوریهای پر زرق و برق و ترس از دست دادن روندها شوند [04:31]. استفاده زودهنگام از ریزخدمات یا ابزارهای پیچیده برای سیستمی که هنوز کاربران محدودی دارد، تنها باعث کندی و پیچیدگی بیدلیل میشود. او پیشنهاد میکند پیش از هر تصمیم فنی، باید دامنه تجاری را به خوبی شناخت و از روشهایی مانند طوفان رویداد و داستانسرایی دامنه برای کشف نیازهای واقعی استفاده کرد [13:42]. این رویکرد به ما کمک میکند تا مرزهای سیستم را به درستی تعیین کنیم و نقشههای بافتار دقیقی بسازیم.
در بخش بعدی تاکید میشود که هیچ معماری کاملی وجود ندارد و همه چیز به شرایط محیطی بستگی دارد [19:25]. عواملی مانند سطح مهارت تیم برنامهنویسی، محدودیتهای بودجه و راهبردهای استقرار باید روی انتخابهای ما تاثیر بگذارند. برای مثال، راهبرد استقرار در یک سیستم پزشکی که خطای آن به قیمت جان انسان تمام میشود، با یک برنامه ساده کاملا متفاوت است [25:49].
هسته اصلی این ارائه معرفی چهار گام تکاملی در طراحی است که شامل سادگی، قابلیت نگهداری، رشد و در نهایت پیچیدگی میشود [32:14]. ماچی توصیه میکند که همیشه کار را با سادهترین حالت ممکن مانند یک معماری یکپارچه اما بخشبندی شده شروع کنیم [35:42]. تنها زمانی باید به سراغ جداسازی خدمات یا افزودن لایههای پیچیده برویم که سیستم واقعا تحت فشار قرار گرفته باشد و هزینه نگهداری آن توجیه منطقی پیدا کند [42:16].
آنچه این رویکرد را ارزشمند میکند، همخوانی آن با توسعه سیستمهای پیچیده است. زمانی که در حال طراحی ساختارهای سطح بالا برای سیستمهای حیاتی و خودتطبیق هستیم، شروع کار با یک مدل ساده و اجرای آن در محیطهای شبیهسازی گام اول است. این معماری به ما یادآوری میکند که پیش از ورود به فاز ارزیابی الگوریتمهای پیچیده یادگیری تقویتی در زمان اجرا، ابتدا باید مرزهای منطقی و اجزای سیستم را در یک ساختار یکپارچه تثبیت کنیم. با افزایش بار پردازشی و نیاز به تصمیمگیری ایمن در لحظه، میتوانیم معماری را بر اساس این نقشه راه به سمت لایههای پیچیدهتر هدایت کنیم تا از درهمتنیدگی بیش از حد اجزا در فازهای اولیه ساخت جلوگیری شود.
«اين مطلب، بخشي از تمرينهاي درس معماري نرمافزار در دانشگاه شهيدبهشتي است»
منابع:
لینک های ویدیو های یوتوب کانال GOTO
