مبانی معماری نرم افزار - بخش پنجم

در بخش چهارم، مساله resiliency و سیستم های resilient را مورد بحث قرار دادیم.

در این بخش در مورد Heuristicها صحبت می کنیم که یکی از مباحث اساسی در Architectural Design است.

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

بنابراین به موضوع استفاده از Heuristicها برای اعمال بهترین تغییر می رسیم. تقریبا در تمام مسائل مهندسی، مساله ها مبتنی بر heuristic هستند. برای مثال در شطرنج یک heuristic می تواند فراهم کردن شرایط حرکت رُخ باشد.

یک heuristic، هر آن چیزی است که یک مسیر یا کمک احتمالا خوبی در مساله است. اما از لحاظ تحلیلی، ممکن است کمک کننده نباشند و یا آسیب زننده هم باشند. بنابراین، یک مجموعه از heuristicها شامل راهنمایی ها، تذکرات و نکاتی در حول محور حل مساله است که در یکسری از contextها موثر هستند اما قابل اثبات هم نیستند.

نکته ای که در مورد heuristicها وجود دارد، این است که وابسته context هستند. نکته بعدی این است که ممکن است heuristicها با هم در تناقض باشند. آن چیزی که در heuristic وجود دارد، مجموعه ای از فرضیات در ذهن کسی است که آن را مطرح می کند.

Properties over Principles

تا زمانی که از لحاظ ذهنی از "اصل" عبور نکنیم، خیلی از موضوعات معنی پیدا نمی کنند. خیلی وقت ها در زمان ارائه راه حل، این مساله را نمی دانیم که principleها به آن معنا اصل نیستند و بیشتر heuristicهایی هستند که قرار است به حل مساله کمک کنند. وقتی نگاه ما کاملا اصول محور باشد، وارد این فضا می شویم که اصل را باید رعایت کنیم نه اینکه مساله را حل کنیم. برای مثال ممکن است به یک طراح بگوییم که این تصمیم به این دلیل اشتباه است که اصل SRP رعایت نشده است.

در حوزه technical، یکی از مشکلات برداشت اشتباه از heuristicها است. لازم است که ادبیات خود را از اصول گرایی به معنای اصل هایی که باید رعایت شوند، به سمت ویژگی هایی ببریم که می خواهیم داشته باشیم. برای مثال Simplicity. در مورد ویژگی هایی صحبت کنیم که باعث ساده سازی می شوند.

در حوزه Technical، به مطالعه heuristicهایی می پردازیم که ممکن است آن ها را به عنوان اصل بشناسید. برای مثال (DRY) Don't repeat yourself. و در حوزه Strategic نیز به مطالعه heuristicهایی می پردازیم که بیشتر ماهیت راهبردی دارند. برای مثال "تصمیمات را تا جای ممکن به تاخیر بیانداز". با هدف بدست آوردن اطلاعات بیشتر از مساله.

به طور کلی در Design چندین موضوع مطرح می شود.

موضوع اول این است که ابهام را به عنوان یک ریسک قلمداد کنیم. از بزرگترین آسیب هایی که در طراحی نرم افزار وجود دارد، مساله ابهام است. زمانی که در مساله ابهام داشته باشیم، قابلیت trade-off را از دست می دهیم. اینکه در مورد مساله شناخت کافی داشته باشیم ولی بسته به شرایطی، بهترین راه حل را انتخاب نکنیم، می تواند کاملا قابل پذیرش باشد. اما زمانی که در مورد مساله ابهام داریم و وارد design می شویم، همیشه با مساله های ناشناخته ای روبرو خواهیم شد.

سوالی که به عنوان یک معمار در طراحی باید زیاد مطرح کنیم، این سوال می باشد که مساله Language را مطرح می کند.

Are we talking about the same thing?

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

Weak / Weakest link

موضوع راهبردی دیگری که وجود دارد، weak یا weakest link است. به این موضوع می پردازد که، بازدهی یک سیستم، به اندازه bottleneck آن است. برای مثال جریان ترافیک یک جاده را bottleneck آن جاده تعیین می کند.

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

زمانی که نام microservice مطرح می شود، ممکن است با این فضا روبرو شوید که یک دیتابیس وجود دارد و در راستای optimize کردن، سرویس ها از همدیگر جدا شده اند. در صورتی که در اینجا، دیتابیس به عنوان یک bottleneck، تاثیر جدی روی سیستم می گذارد.

به توضیحات بیشتری در مورد DRY به عنوان یک heuristic در حوزه technical بپردازیم. چه دغدغه هایی در پشت DRY وجود دارد؟ زمانی که از زاویه code duplication به مساله نگاه کنیم، مساله به این سمت می رود که هدف ما جلوگیری از تکرار کد باشد. اما DRY در مورد تکرار کد صحبت نمی کند و بحث آن عدم تکرار دانش است. در مورد DRY دو موضوع maintainability و learnability وجود دارد. اگر بخواهیم آن را بهتر تشریح کنیم، می توانیم بگوییم knowledgeها در یک ساختار باید در یکجا وجود داشته باشند.