مروری بر چندین سخنرانی نسبتاً جدید مرتبط با معماری نرم افزار

در اینجا خلاصه‌ای از ویدئو با عنوان " Keynote by Magnus Martensson at Software Architecture Conference 2023" بیان شده است:

در این ویدئو، مگنوس مارتنسون خود را معرفی کرده و علاقه‌مندی اش به فناوری‌های ابری و شرکت در جامعه Global Azure را بیان کرده است. او همچنین به اهمیت رویدادهای جامعه و به اشتراک‌گذاری دانش در زمینه معماری نرم‌افزار توجه دارد.

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

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

در ادامه موضوع "قفل شدن به تامین‌کننده (Vendor Lock-In)" در زمینه خدمات ابری صحبت میشود که اهمیت انتخاب آگاهانه خدمات ابری بسیار مهم است. شرکت‌ها باید موازنه‌گرانه و با دقت تصمیم‌هایی در مورد استفاده از خدمات ابری بگیرند، زیرا وابستگی به تامین‌کنندگان خاص می‌تواند به مشکلات و ریسک‌هایی مانند مشکلات مالی و عملیاتی، محدودیت‌های استراتژیک، و کاهش انعطاف‌پذیری منجر شود. معماران نرم‌افزار باید تصمیم‌های معماری بگیرند که امکان حمل و تطبیق برنامه‌ها را با فناوری‌ها یا خدمات مختلف فراهم کنند. از انتزاعات مانند رابط‌ها و پروکسی‌ها استفاده شود تا برنامه‌ها به طور زیادی به یک فناوری یا خدمت خاص وابسته نشوند. این رویکرد امکان مهاجرت یا تطبیق برنامه‌ها با تغییرات درخواستی یا فناوری‌ها را بهبود می‌بخشد و ریسک‌های مرتبط با وابستگی نادرست به تامین‌کنندگان را کاهش می‌دهد.

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

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

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

در اینجا خلاصه‌ای از ویدئو با عنوان " Democratising Software Architecture • Eoin Woods • GOTO 2023" بیان شده است:

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

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

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

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

در ادامه، اوین وودز به ایده "معماری به عنوان یک مسئولیت مشترک" اشاره می‌کند. او تأکید می‌کند که معماری نرم‌افزار نباید تنها مسئولیت معماران باشد و باید به عنوان یک وظیفه مشترک بین تمام اعضای تیم معنا شود. وی به اهمیت درک و تطبیق معماری با تغییرات و نیازهای متغیر پروژه تأکید می‌کند. این مفهوم به تشویق همکاری و تعامل بین اعضای تیم برای تحقیق بهترین معماری نرم‌افزار و پیشبرد اهداف پروژه کمک می‌کند.

به طور کلی هدف این کنفرانس تأکید به این است که معماران نرم‌افزار و تیم‌ها باید تغییر و انعطاف‌پذیری را در رویکرد به معماری نرم‌افزار خود پذیرا باشند. به اهمیت یادگیری پیوسته و تطور در زمینه معماری نرم‌افزار اشاره میشود. وودز به تغییرات در منظر معماری نرم‌افزار اشاره می‌کند و اهمیت یک رویکرد همکارانه و قابل تطبیق به مسئولیت‌های معماری را تأکید می‌کند.

در اینجا خلاصه‌ای از ویدئو با عنوان "Programming's Greatest Mistakes • Mark Rendle • GOTO 2023" بیان شده است:

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

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

او به بررسی باگ Y2K می پردازد. این اشکال نتیجه استفاده از دو رقم برای سال در تاریخ بود که با نزدیک شدن به سال 2000 منجر به خرابی احتمالی سیستم شد. تلاش های بسیاری برای رفع این اشکال انجام شد و حدود نیم تریلیون دلار هزینه داشت. رندل یک باگ جدیدتر در Microsoft Exchange را بیان می‌کند، که در آن سیستم نمی‌تواند تبدیل تاریخ خاصی را انجام دهد. این مثال نشان می دهد که مشکلات مشابه با باگ Y2K هنوز در سیستم های مدرن رخ می دهد. همچنین در این ویدئو مشکل 2038 Unix Time Overflow بیان شده است، جایی که مقدار زمان 32 بیتی یونیکس سرریز می شود و باعث ایجاد مشکلاتی مشابه Y2K می شود.

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

رندل با انتقاد از پیچیدگی و ناکارآمدی نرم افزارها و فرآیندهای سازمانی، به Scaled Agile Framework به عنوان نمونه ای از پیچیدگی بیش از حد در صنعت اشاره میکند. او استدلال می کند که چنین چارچوب هایی می توانند پیچیدگی های غیرضروری را به توسعه نرم افزار اضافه کنند.

خطای ممیز شناور Intel Pentium: رندل با بحث درباره اشتباه پرهزینه اینتل توضیح می دهد که چگونه واحد ممیز شناور پردازنده پنتیوم آنها منجر به محاسبات نادرست شده است. این خطا منجر به ایجاد هزینه‌ی 475 میلیون دلاری شد که نشان دهنده ریسک بالای اشکالات سخت افزاری بود.

مفهوم «Null» یک اشتباه میلیارد دلاری در این ویدئو خوانده شده است. Null توسط تونی هور معرفی شده است و دلیل خوانده شدن آن به عنوان یک اشتباه، ایجاد خطاها و مسائل متعددی در برنامه نویسی است. این بخش از گفتگو بر تأثیر مفاهیم اساسی برنامه نویسی بر قابلیت اطمینان نرم افزار تأکید می کند.

رندل به فروپاشی مرکز مدنی هارتفورد اشاره میکند که در آن خطاهای برنامه نویسی در نرم افزار CAD منجر به خرابی ساختاری در یک ساختمان شد که 90 میلیون دلار هزینه داشت. این مورد ضررهای دنیای واقعی را نشان می دهد که می تواند از خطاهای نرم افزاری ناشی شود.

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

در اینجا خلاصه‌ای از ویدئو با عنوان " Software Design in the 21st Century - Martin Fowler - XConf Thailand 2019" بیان شده است:

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

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

مارتین فاولر به مدل Agile Fluency اشاره می‌کند. این مدل یک چارچوب است که تأکید دارد تیم‌ها از طریق مراحل مختلفی از چابکی (Agility) پیشرفت می‌کنند و در مراحل مختلف چابکی تکامل می‌یابند، که هر کدام به مجموعه‌ای از مهارت‌ها و تمرکز نیاز دارند. او در این بخش تأکید می‌کند که مهارت‌ها و تمرین‌های فنی در دستیابی به چابکی بسیار اهمیت دارند و به تعدادی از تمرین‌ها و مهارت‌های کلیدی اشاره می‌کند که نقش مهمی در دستیابی به چابکی ایفا می‌کنند:

· (Continuous Integration) یکی از مهمترین تمرینات در روش‌های چابک است. این تمرین به معنای ادغام مکرر تغییرات کد به شاخه اصلی کد یا مخزن اصلی می‌باشد. این تمرین به جلوگیری از ادغام‌های پیچیده و خطاگیرانه کمک می‌کند و با تضمین ادغام مکرر تغییرات، مشکلات ادغام را در زمان به موقع شناسایی می‌کند و تضمین می‌کند که پایگاه کد در طول چرخه توسعه پایدار و قابل اعتماد باشد.

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

· Self-Testing Code به معنای نوشتن تست‌هایی است که به عنوان یک سیستم تشخیص خطا در کد عمل می‌کنند و به حفظ کیفیت کد و امکان بازنویسی کد کمک می‌کنند.

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

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

در اینجا خلاصه‌ای از ویدئو با عنوان " Software Architecture and Design InfoQ Trends Report 2022" بیان شده است:

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

مفهوم Data Mesh و Data Gateway به عنوان یک رویکرد نوین در مورد سازماندهی داده بررسی میشود. این مفهوم مشابه طراحی محور حوزه (Domain-Driven Design) است، اما در اینجا برای داده‌ها به کار می‌رود. اصلی‌ترین ایده این است که تیم‌ها را بر اساس حوزه‌های داده تشکیل داده تا مدیریت و کیفیت داده‌ها بهبود یابد. این رویکرد داده‌ها را به عنوان یک منبع مستقل و توزیع‌شده در نظر میگیرد و دسترسی به داده‌ها و مدیریت آنها را آسان میکند.

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

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

در رابطه با سوابق تصمیمات معماری (ADRs) یک ابزار برای ثبت و انتقال تصمیمات معماری صحبت شده است. این رویکرد به تیم‌ها کمک می‌کند تا یک سوابق دقیق از دلایلی که باعث انتخاب یک معماری خاص شدند، نگهداری کنند. به این ترتیب، اطلاعات مهمی در مورد چرایی‌های تصمیمات معماری در دسترس تیم‌ها قرار می‌گیرد و ارتباط و تبادل دانش در مورد معماری تسهیل می‌شود. مورد دیگر اینکه نیاز به تقویت تیم‌ها برای انجام تصمیمات معماری مورد تأکید قرار می‌گیرد و اختیار دادن به تیم‌ها برای تصمیم‌گیری در مسائل معماری از اهمیت ویژه‌ای برخوردار است.

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

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

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