شماره تماس 09336863931 | 09178169907 پست الکترونیک provid.ir@gmail.com

بررسی Domain Driven Design و رسالت آن در توسعه نرم افزار #3

بررسی Domain Driven Design و رسالت آن در توسعه نرم افزار #3 را در این قسمت از وبسایت آموزش برنامه نویسی پرووید دانلود کنید.

بررسی Domain Driven Design و رسالت آن در توسعه نرم افزار #3

یکی دیگر از روش هایی که سعی به شکستن سیکل CRAP می کند ریفکتورینگ است. ریفکتورینگ به برنامه نویس این امکان را می‌دهد تا تغییرات درونی و ساختاری یا همان Structural را به جای اعمال کردن Patch های در زمان نگهداری نرم افزار اعمال کند. زمانی که ریفکتورینگ در کنار Test Driven Development استفاده می‌شود می‌تواند کیفیت کد یا همان Code Quality را حفظ و یا حتی آن را بهبود ببخشد. این کیفیت کد زمانی که تغییراتی بر روی کد ایجاد می‌کنیم دست نخورده باقی می ماند. البته اغلب مدیر پروژه می‌تواند با ریفکتورینگ مخالف باشد چون ریفکتورینگ نیاز به هزینه های زمانی و مالی دارد و اغلب بر روی خروجی نهایی نرم افزار اثری نمی‌گذارد. به عبارت دیگر ممکن است شما مدیری را در پروژه داشته باشید که از شما بپرسد: “زمانی که این ریفکتورینگ شما پایان می یابد آیا نرم افزار سریع تر اجرا میشود؟ آیا نرم افزار خطاهای کمتری خواهد داشت؟ طبیعتاً جواب شما “خیر” است. چرا که انجام ریفکتورینگ بر روی کد دقیقاً همان خروجی را تولید خواهد کرد که نرم افزار از قبل داشته است. اگر این جواب را به مدیر پروژه دهید شک ندارم که به شما خواهد گفت: “بنابراین ریفکتورینگ را کنار بگذار و به کاری بپردازد که در روند پروژه مفید باشند.”

آخرین راه حل برای شکستن سیکل CRAP برنامه ریزی یا همان Planning است. به عبارت دیگر معماری کردن نرم افزار برای طاقت آوردن در تغییراتی که در طی زمان اتفاق خواهد افتاد. در چنین سناریویی فعالیت‌های Maintenance همانطور هندل می شوند که فعالیت‌های Development هندل می‌شوند. به عبارتی دیگر هزینه زمانی و مالی یکسان بر روی طراحی و تجزیه تحلیل که در نرم افزار اولیه انجام می‌شد بر روی Maintenance نیز انجام می‌ شود. دقیقاً شبیه اتفاقی که ممکن است برای ریفکتورینگ بیفتد ممکن است برای Planning نیز بیفتد. به عبارتی کسی پیدا نشود که حاضر باشد هزینه های زمانی و مالی این روش را به عهده بگیرد. موضوع دیگر اینکه Planning اغلب با شکست مواجه می‌شود چرا که ما نمی‌توانیم تغییراتی که در آینده بر روی نرم افزار به وجود خواهند آمد را به طور کامل پیش بینی کنیم.

طبیعتاً این قضیه ما را به سمت برنامه نویسی چابک یا همان Agile Development می رساند. بر اساس برنامه نویسی چابک ما برنامه ریزی های بلند مدت را کنار می‌گذاریم چرا که در پیش‌ بینی آنها خوب نیستیم و تمرکز را بر روی چیزی می گذاریم که هم اکنون در حال انجام دادن آن هستیم. به عبارت دیگر مدیریت طولانی مدت کنار گذاشته می‌شود و تمرکز بر روی مدیریت کوتاه مدت قرار میگیرد.

نظر بدهید

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