برگردیم به طراحی!

  • یوسف مهرداد

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

 

پرسش‌ها:
دیروز از چند تن از دوستانم که در جمعی حاضر بودند خواهش کردم که به سه پرسش زیر فکر کنند و به آن پاسخ بدهند.

پرسش اول: اگر پیاده‌سازی یک ویژگی جدیدِ سیستم به شما سپرده شود، چگونه و طی چه گام‌هایی آن را به کد تبدیل می‌کنید؟ (تاکید روی بخش طراحی است)

پرسش دوم: اگر قرار باشد راهنمای یک برنامه‌نویس باشید تا ویژگی جدید را پیاده‌سازی کند، مراحل انجام این کار را در قالب چه گام‌هایی به او خواهید آموخت؟ (تاکید روی آموزش طراحی حین کار است)

پرسش دوم: اگر قرار باشد پیاده‌سازی یک ویژگی جدید را در یک کلاس آموزشی به شاگردان آموزش دهید، آموزش شما شامل چه بخش‌هایی خواهد بود؟ (تاکید روی آموزش عمومی طراحی است)

گزیده:
اعمال یک تغییر در کد ممکن است منجر به ایجاد زنجیره‌ای از تغییرات در نرم‌افزار شود که دلیل آن، وجود وابستگی (coupling) بین اجزای نرم‌افزاری است. در نتیجه هزینه‌ی این تغییر برابر است با جمع هزینه‌ی کل این تغییرات. از سوی دیگر، کاهش یا حذف وابستگی بین این اجزای وابسته (decoupling) نیز نیازمند صرف هزینه‌ است.
از این رو به عنوان برنامه‌نویس همواره ناچارید بین هزینه‌ی تجمیعی زنجیره‌ی تغییرات ناشی از وابستگی (coupling) و هزینه‌ی لازم برای جداسازی آنها (decoupling)، یکی را انتخاب کنید (trade-off).
کنت بک

https://bibalan.com/?p=3648
یوسف مهرداد

یوسف مهرداد


کانال تلگرام

دیدگاهتان را بنویسید

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

برای خروج از جستجو کلید ESC را بفشارید