در مطلب قبلی معیارهای یک طراحی خوب را از زبان آقای Meyers، بیان کردیم.
در اینجا می خواهیم بدانیم تلاش برای داشتن یک طراحی خوب چقدر ارزشمند است.
در این پست، منظور از طراحی، طراحی نرم افزار است که دارای جنبه های مختلفی است. برخی از آن عبارتند از:
- طراحی معماری
- طراحی کلاس ها
- طراحی واسط کاربری
- طراحی بانک اطلاعاتی
- طراحی الگوریتم
- طراحی پروتکل
مهمترین مسأله ای که باید در یک طراحی خوب در نظر گرفت، اهداف طراحی است. طراحی خوب، طراحی است که به اهداف ما از طراحی نرم افزار منجر شود. البته این اهداف، اهداف ذینفعان است که بانیان اصلی تولید نرم افزار هستند.
در زیر به برخی از این اهداف اشاره می کنیم:
- افزایش سود خالص با کاهش هزینه های تولید و افزایش درآمد که برای بیشتر سازمانها این مهمترین هدف است.
- حصول اطمینان از پوشش دادن نیازمندی های مشتری و حل مسائل وی
- شتاب دادن به توسعه. که این هدف باعث کوتاه مدت شدن هزینه ها می شود و اطمینان می دهد که نرم افزار برای یک رقابت موثر و به موقع(در زمان تعیین شده توسط مشتری) به بازار ارائه می گردد.
- افزایش شاخص های کیفیت مانند usability، efficiency، reliability، maintainability و reusability که خود به نحوی باعث پایین آمدن هزینه ها و افزایش درآمد می شود.
طراحی نرم افزار، اتخاذ تصمیمات طراحی برای حل مسائل است. پرواضح است که در هر انتخاب، برای اینکه چیزی را بدست آوریم ناگزیریم چیزهایی را از دست بدهیم(قانون بقای طراحی!!). بنابراین سبک و سنگین کردن در طول طراحی پروژه و برقراری توازن بین اهداف(افزایش کیفیت، پایین آمدن هزینه تولید) شرط اصلی داشتن یک طراحی خوب است. البته این نکته را در نظر داشته باشیم که بالا بودن کیفیت نرم افزار ممکن است در بالا رفتن مقطعی هزینه ها، نقش مستقیم داشته باشد، اما در بیشتر موارد، در طول زمان، این هزینه ها به پروژه باز می گردد(با پایین آمدن هزینه توسعه و نگهداری).
James Shore در مقاله خود(Quality With a Name) اینطور می گوید:
A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.
در این مقاله کیفیت طراحی اینگونه تعریف می شود:
Design quality = change / developer time
برای گرفتن کامل این مطلب توصیه می کنم این مقاله ارزشمند را به طور کامل مطالعه کنید.
برای کامل تر شدن بحث از مقاله آقای Fowler کمک می گیریم. در این نمودار محور cumulative functionality همان قابلیت تجمعی(نه قابلیت مقطعی) است.
این نمودار نشان می دهد که نداشتن طراحی(عدم تلاش برای یک طراحی خوب) باعث پیشرفت سریع پروژه در ابتدای مسیر می شود اما به مرور زمان Productivity و کیفیت نرم افزار رو به افول می گذارد. نداشتن طراحی خوب باعث می شود تا به مرور زمان اعمال تغییرات در نرم افزار با سختی بیشتری انجام شود. در صورتی که با داشتن طراحی خوب، Productivity پایدارتر خواهد بود. نکته اینکه این دوخط(good design و no design) در نقطه ای از زمان یکدیگر را قطع می کنند. خط فرضی که از این تقاطع عبور می کند(design payoff line)، نقطه تصمیم گیری است. یعنی اگر میزان قابلیت های تجمعی نرم افزار شما در طول زمان زیر این خط فرضی باشد، عدم تلاش برای یک طراحی خوب تصمیم بهتری است و بالعکس٫ در واقع تصمیم گیری بر اساس این انجام می شود که قابلیت های این نرم افزار در آینده قرار است تا چه اندازه توسعه داده شود.
البته در عمل ممکن است رسم چنین نموداری و پیدا کردن این خط فرضی در مورد یک نرم افزار امکان پذیر یا قابل تست و اثبات نباشد. اما مهم استفاده از این ایده و تجربیات در تصمیم گیری نهایی است.
از نظرات دوستان در تکمیل این مطلب استقبال می کنم.
دیدگاه هاي اخير