خانه / microservices / Software Behavior and Architecture

Software Behavior and Architecture

جدال ناتمام معماران نرم افزار و مدیران ذینفع سازمان

  1. مقدمه

یکی از جدال ها و بحث های تمام نشدنی تاریخ را می توان در جدال میان افراد فنی و بخصوص علاقمند به پرکتیس های فنی و الگوهای طراحی نرم افزار با سایر افراد بیزینسی مشاهده نمود.! جایی که هر کس از دید خود و بر اساس مایندست ذهنی خود به بحث بر سر نرم افزار که اکثر اوقات در میان این جدال نا تمام مهجورترین کس می باشد؛ می پردازند. موردی که معمولا بدلیل اینکه دو طرف درگیر؛ دارای دو ذهنیت جداگانه نسبت به یک مسئله واحد هستند به نتیجه ی مناسبی ختم نمی شود. مدیر و ذینفعان؛ رفتار نرم افزار و کار کردن نرم افزار برای مشتری در کمترین زمان ممکن برای گرفتن مارکت را طلب می کنند. و افراد تکنیکالی که به ساختار نرم افزار تمرکز دارند و دغدغه های تکنیکال رو ارجحتر می بینند و بدنبال اعمال good practice ها و طراحی مناسب به قیمت از دست رفتن زمان هستند آنهم به این دلیل که ممکن است هزینه ی ریلیز سریعتر فعلی را مدتی بعد مجبور باشیم سنگین تر بپردازیم. این که واقعا چه کسی حق دارد و باید کدام تصمیم را گرفت یک امر کاملا شفاف نیست و نمی توان نسخه ای واحد برای آن پیچید. و این بسته به شرایط می باشد.

Uncle Bob دو جنبه و ارزش مختلف و متفاوت را برای هر محصول نرم افزاری قائل شده:

  • Behavior Value
  • Structure Value

و بیان می کنه که دید و مایندست ذینفعان بیشتر ناظر بر ارزش Behavior بوده و در طرف مقابل معماران نرم افزار بیشتر تمرکز دارند بر ارزش ها و جنبه های Structure.

در این مقاله کوتاه سعی خواهد شد که گریزی بر این دو جنبه زده شود و با ماتریکس Eisenhower بکه هنگام افتادن در دام این جدال ناتمام می تواند به عنوان معیار و متریکی مناسب استفاده شود را معرفی خواهم کرد.

  1. Behavior

اولین ارزش هر نرم افزار کارکرد و رفتار سیستم جهت تولید ارزش(پول) برای ذینفعان است. از این دیدگاه وظیفه ی برنامه نویس تولید و پیاده سازی عملیاتی در سیستم می باشد که برای دینفعان کسب درآمد کند. تنها هدف در اینجا تولید نرم افزار جهت تولید ارزش برای ذینفعان می باشد.

  1. Structure

جنبه ی دوم اما اشاره به معماری نرم افزار دارد. باب اشاره می کنه که هر چند جنبه ی اول ناظر بر بخش ware از محصول نرم افزاری است (ware به معنی product) این جنبه به قسمت soft تمرکز و اشاره دارد. در واقع بخش soft اشاره به این واقعیت دارد که یک محصول نرم افزار باید بگونه ای soft تولید شود که بتوان در صورت نیاز behavior سیستم را تغییر داد؛ در غیر اینصورت به آن hardware گفته می شد. در نتیجه باید سیستمی تولید کرد که دارای خاصیت soft باشد. باید توجه داشت که این soft بودن بیشتر از دیدگاه ذینفعان نیز مثبت به شمار خواهد آمد بخصوص بهنگام تغییر مایندست و نیازمندیهای فعلی سیستم و نرم افزار. نکته ی بسیار مهمی که در اینجا باب اشاره می کند این است که: سختی موجود در این قسمت باید محدود به scope تغییرات باشد و نه در مورد شکل و shape تغییرات مورد نیاز در هر زمان. در نتیجه soft بودن؛ جهت عدم تغییر و یا کم/زیاد کردن shape تغییرات مورد نیاز ذینفعان در هر زمان بسیار مهم و اساسی می باشد.

همین تفاوت ریز میان shape و scope تغییرات می باشد که تفاوت دیدگاه اساسی میان معماران نرم افزار و ذینفعان ایجاد می کند. از نظر ذینفعان آنها فقط یک تغییرات کوتاه با shape مشخص را طلب کردند؛ این در حالی است که از دیدگاه معماران نرم افزار این تغییرات دارای scope ای بیش از حد و ناخواسته می باشد که ممکن است تاثیرات ناخواسته بر رفتار نرم افزار داشته باشد؛ در نتیجه آنها تلاش می کنند که با تغییر در shape تغییرات مورد نظر ذینفعان؛ scope این نیازمندی ها را کنترل کنند.!

  1. Behavior یا Structure؟

اما کدام یک از این دوجنبه مهم تر و ارجحتر می باشد. کار کردن نرم افزار مهم تر است یا اینکه داشتن محصولی نرم افزاری که در حال حاظر کار نمی کند اما؛ در برابر تغییرات احتمالی منعطف می باشد.

طبیعی است که توسعه دهنده مورد دوم و مدیر و ذینفع نرم افزار مورد اول را ارجح تر می دانند.  باب با آوردن مثال زیر بیان می کند که توسعه دهنده ممکن است برای اثبات ادعای خود جملات زیر را بیان کند:

  • اگه از من نرم افزاری بخوای که الان کار کنه ولی فردا روز بهنگام نیاز به تغییر این امر امکان پذیر نباشد؛ و من نتونم این تغییرات رو اعمال کنم در نتیجه اون موقع سیستم تو usefulness خواهد شد و ارزشی برای تو و مشتریانت نمی تونه ایجاد کنه.
  • اگه نرم افزاری از من بخوای که الان کار نکنه ولی بشه راحت تر نیازمندیهاتو بهنگام نیاز درش اعمال کنی؛ من می توانم کاری کنم که اون برای تو در آینده ی نزدیک کار کنه. و البته چون میتونی تغییرات مورد نیازت رو اعمال کنی این سیستم همچنان برای تو در آینده هم ارزشمند خواهد بود.

هرچند این یک مکالمه اغراق آمیز می باشد ولی باب اشاره می کنه که کمتر ذینفعی ممکن است سیستمی طلب کنه که بعد اگر اعمال تغییرات در آن ناممکن نباشد بسیار هزینه بر باشد. از طرف دیگر اما در صورتی که از مدیری گفته شود که آیا سیستمی را می خواهد که در آینده بتوان براحتی تغییرات مورد نیاز را اعمال کرد؛ بی شک پاسخ او بله می باشدJ اما اکثر اوقات خواهیم شنید که behavior و functionality فعلی سیستم از اولویت بالاتری نسبت به داشتن سیستم منعطف در برابر تغییرات برخوردار می باشد. از طرف دیگر اما در صورتی که مدیر و ذینفعی از شما تخمین اعمال تغیری در سیستم را بخواهد و شما یک تخمین با هزینه زیاد به او ارائه کنید مدیر مورد نظر ممکن است که اجازه دهد که سیستم از نظر structure به نقطه ای برسد که اعمال تغییرات مورد نیاز در آن هزینه ی کمتری را طلب کند. خوب حد این موضوع کجاست.! ماتریکس Eisenhower به ما در این مورد کمک می کند.

  1. Eisenhower Matrix

Dwight D.Eisenhower در یکی از سخنرانی خود اشاره کرد که که من دو نوع مسئله همواره خواهم داشت که از دو جنبه ی importance و urgency با هم متفاوت می باشند.

من با دو نوع خاص از مسائل مواجه هتسم؛ urgent و important. مسائل urgent هیچگاه important نیستند و موارد important نیز urgent نمی باشند.

در نرم افزار نیز ما با دو مسئله متفاوت مواجه هستیم. ارزش اول نرم افزار-Behavior؛ جز مسایل urgent هستند اما همیشه important نمی باشند.

ارزش دوم نرم افزار –Architecture جز موارد important هستند ولی همواره urgent نیستند.

از این نظر ما با چهار دسته مسئله بصورت زیر مواجه هستیم:

  • Urgent and important
  • Not urgent and important
  • Urgent and not important
  • Not urgent and not important

خوب همانطور که مشاهده می کنیم جنبه ی Architecture (important) در دو جایگاه اول و سوم از ماتریکس بالا قرار داره؛ این در حالی است که behavior در جایگاه اول و سوم قرار دارد. باب اشاره می کنه که اشتباه عمده ای که توسعه دهنده و ذینفعان مرتکب می شوند این می باشد که مسائل موجود در سطح سه را به سطح یک منتقل می کنند. به بیان دیگر در تمیز قائل شدن میان ویژگی هایی که urgent و unimportant هستند با مواردی که urgent و important می باشند دچار اشتباه خواهند شد. نتیجه این امر صرفنظر کردن از مسائل important architecture سیستم در مقابل مسائل و فیچرهای urgent و unimportant می باشد. خوب این اشتباه رایج طبیعی می باشد. از نقطه نظر مدیر و ذینفعان محصول urgent ها بالاترین اهمیت را دارد و این بر عهده توسعه دهنده و معماران نرم افزار می باشد که به مسائل از نوع important architecture و روشن کردن این مسائل میان ذینفعان اقدام کند.

  • نتیجه گیری

توجه تومان به soft و ware و نگاه ویژه به soft در جایگاه اول و دوم ماتریکس Eisenhower یکی از مهمترین دغدغه های معماران نرم افزار و ذینفعان سیستم باشد. باید توجه داشتیم که مسائلی که ما با آنها مواجه هستیم گاها urgent هستند ولی important نیستندو به عکس؛ تمیز قایل شدن میان این دو دسته از مسایل بهنگام توسعه محصول می تواند بسیار مهم باشد. هر چند behavior و functionality سیستم هم جز مباحث urgent می باشد ولی این مسایل در جایگاه دوم و سوم ماتریکس Eisenhower قرار دارد؛ و به عکس مباحث مرتبط با architecture در دو سطح اول و دوم قرار دارد؛ یکی از اشتباهات رایج آوردن مسایل سطح سوم یعنی مسایلی که urgent هستند ولی important نمی باشند به سطح اول باعث دور شدن از مسیله مهمتر یعنی مسیله ای که هم urgent هست و هم important خواهد شد. جهت کمک به تمیز قایل شدن و جلوگیری از افتادن در دام این مشکل نقش معماران و برنامه نویس های نرم افزاری بسیار مهم می باشد.

  • منبع

Clean Architecture, A Craftsman’s Guide to Software Structure and Design, Robert C.Martin, Prentice HALL , 2018

 

درباره ی masoud@admin

همچنین ببینید

مقدمه بر معماری و کتاب Clean Architecture

مقدمه بر معماری و کتاب Clean Architecture Uncle Bob   نام Uncle Bob را همگی …

Serverless Architecture for an IoT solution xconf eu 2017

Serverless Architectures معماری Serverless که به عنوان یکی از Deployment Strategy های مورد در استفاده …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن