حسام حداد تکنولوژی، برنامه‌نویسی، هوش مصنوعی

مقدمه

پیش از این راجع به Bad Smell صحبت کردیم "کلاس بزرگ" یکی از 22 نوع Bad Smell میباشد.

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

شما میتوانید از روش استخراج کلاس[1] برای کم کردن تعداد متغیر استفاده کنید. متغیر ها را طوری انتخاب کنید که در کنار هم معنا دار باشند. برای مثال depositAmount و depositCurrency احتمالا باید در یک کلاس باشند. در حالت کلی پیشوند یا میانوند اسم متغیر ها در یک کلاس نشانه یک فرصت برای ساخت کلاس جدید است. اگر این متغیر ها در کنار هم به شکل یک زیرکلاس معنا دار تر میشوند میتوانید از روش استخراج زیرکلاس[2] نیز استفاده کنید.

ادامه مطلب

مقدمه
پیش از این راجع به Bad Smell صحبت کردیم "تابع طولانی" یکی از 22 نوع Bad Smell میباشد.

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

مقدمه

پیش از این راجع به Bad Smell صحبت کردیم "کد های تکراری" یکی از 22 نوع Bad Smell میباشد.

نحوه تشخیص و معرفی راه حل کد های تکراری

اولین بوی بد کد های تکراری هست اگر شما یک ساختار کد را در بیشتر از یک مکان میبینید میتوانید مطمئن باشید که نرم افزار با یکی کردن آنها بهتر می شود.
ساده ترین مشکل وقتی هست که شما یک تکه کد را در دو تابع مختلف یک class دارید در این صورت تنها کافیست یک تابع استخراج کنید و در جای مناسب تابع را صدا بزنید. مشکل رایج بعدی وقتی هست که شما یک کد را در دو class که باهم sibling  هستند دارید ( کلاس هایی که از یک کلاس دیگر مشتق شده اند) در این صورت شما میتوانید متد را در دو کلاس استخراج کنید و بعد به class پدر منتقل کنید.
اگر کد شبیه است اما تفاوت هایی دارد شما نیاز به بخش بندی کردن کد برای جداسازی بخش مشترک با بخش متفاوت دارید. پس از آن ممکن است بتوان تشخیص داد که با  راه حل Form Template Method نیز  مشکل تفاوت ها قابل حل هست. اگه دو متد یک کار را با دو الگوریتم متفاوت انجام می دهند بهتر است الگوریتم clear تر انتخاب شود.
اگر در دو کلاس نا مرتبط کد تکراری دارید راه حل استخراج Class و استفاده از Class جدید در محل های تکرار را مد نظر داشته باشید. احتمالات دیگری نیز ممکن است رخ دهد مثلا اینکه این تابع می بایست در یکی از Class ها قرار می گرفته و در دیگری صدا زده می شده یا در Class سومی قرار میگرفته و توسط هر دو کلاس صدا زده می شده شما باید تصمیم بگیرید که کد کجا معنی دار میشود و مطمئن شوید که مکان درست همانجا می باشد.

مقدمه مترجم

مطالب زیر از نسخه اصلی کتاب Refactoring: Improving the Design of Existing Code  نوشته Martin Fowler دستچین شده و با ترجمه همراه با تالیف برای درک بهتر مطلب آمده است. Code Refactoring به شما یک سری عادت مفید در برنامه نویسی می آموزد که بسیار میتواند باعث کیفیت بخشیدن به نرم افزارتان شود. مطالب در این رابطه به مرور روی وبلاگ قرار می گیرند و به امید خدا این مطالب را در ویکی پدیا فارسی هم در بخش Code Refactoring اضافه خواهم کرد.

Refactoring یا بازآرایی چیست؟

بازآرایی فرایند تغییر یک سیستم نرم افزاری به گونه ای است که رفتار خارجی تغییر نکند و ساختار داخلی بهبود یابد. این یک روش منظم برای پاکسازی کد به گونه ای هست که شانس رخدادن خطا کاهش یابد. درواقع بازآرایی کردن معادل بهبود طراحی کد بعد از نوشته شدن می باشد.
"بهبود طراحی پس از نوشته شدن کد" عبارت عجیبی است زیرا با درک حال حاضر ما از توسعه نرم افزار ما بر این باور داریم که اول طراحی میکنیم و بعد برنامه نویسی را انجام میدهیم. یک طراحی خوب داریم و بعد از آن سراغ برنامه نویسی می رویم. پس از گذشت زمان کد و درستی سیستم تغییر پیدا میکند و ساختار طراحی بمرور محو میشود. کد به آرامی از فرآیندی مهندسی به فرآینی شبیه خنثی سازی بمب شبیه میشود.

ادامه مطلب