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

در مورد Code Refactoring و بازآرایی کد دو سال قبل یک مجموعه پست در وبلاگ منتشر شد. به تازگی آرین یک سند کاملتر و با جزئیات و مثال‌های برنامه‌نویسی در C# در مورد Code Refactoring آماده کرده و به رایگان منتشر کرده، مثال‌های عملی C# در Code Refactoring رو می‌تونید توی این سند پیدا کنید.

بهسازی کدهای کامپیوتری با مثال‌های C#

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

ادامه مطلب

مقدمه

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

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

توضیحات مارا به کد بدی منتهی میکند که میتواند تمامی بو های بد قبلی را داشته باشد در اولین حرکت ما بایست بوی بد را با refactor از بین ببریم سپس وقتی اینکار تمام شد معمولا به نقطه ای میرسیم که توضیحات بی فایده میشوند.

اگر شما نیاز دارید یک توضیح برای تشریح هدف یک تکه کد بنویسید. روش استخراج متد را استفاده کند اگر متد وجود دارد اما باز نیاز به توضیح دارد روش نامگذاری دوباره متد[1] را امتحان کنید. اگر نیاز دارید قوانینی برای سیستم تعریف کنید از معرفی تاکید[2] استفاده کنید.

[1] Rename Method
[2] Introduce Assertion

مقدمه

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

نحوه تشخیص و معرفی راه حل میراث بدردنخور
زیر کلاس ها تمام متد ها و فیلد های پدران را به ارث میبرند ولی وقتی چیزی که میگیرند را نخواهند چه باید کرد؟

تفکر سنتی میگوید  که این به معنی اشتباه بودن سلسله مراتب است شما باید یک کلاس مجاور دیگر درست کنید و با روش های پایین آوردن متد[1] و پایین آوردن فیلد[2] تمامی متد های استفاده نشده را به کلاس مجاور منتقل کنید  و به این طریق کلاس پدر تنها بخش مشترک را نگه میدارد معمولا این طور می شنوید که superclass ها باید abstract باشند.

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

بوی میراث بدرد نخور وقتی شدید میشود که کلاس زیر در حال استفاده از برخی قابلیت هاست اما نمیخواهد interface کلاس پدر را پشتیبانی کند. ما راجع به رد پیاده سازی بی تفاوت بودیم اما در مورد رد interface قضیه جدی تر میشود. در این حال به سلسله مراتب نچسبید و با روش جایگزینی همراهی با وراثت[3] مشکل را برطرف کنید.

[1] Push Down Method
[2] Push Down Field
[3] Replace Inheritance with Delegation

مقدمه

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

نحوه تشخیص و معرفی راه حل کلاس داده
این کلاس ها متغیر دارند متد های get و set برای آن فیلد ها دارند و هیچ چیز دیگری ندارند. این کلاس ها نگه دارنده های احمق اطلاعات هستند و معمولا زیادی توسط کلاس های دیگر دستکاری می شوند. اوایل ممکن است این کلاس ها فیلد های public داشته باشند اگر چنین است شما باید سریعا روش کپسول سازی فیلد[1] را به کار ببرید، اگر فیلد های مجموعه ( مثل آرایه ، لیست پیوندی و ...) دارید مطمئن شوید که روش کپسوله سازی مجموعه را به کار بردید. روش حذف متد های تنظیم[2] را برای هر فیلدی که نیاز نیست تغییر کند اعمال کنید.

[1] Encapsulate Field
[2] Remove Setting Method

مقدمه
پیش از این راجع به Bad Smell و کاربرد آن در مهندسی نرم افزار صحبت کرده بودیم در ادامه با دو نوع Bad Smell آشنا می شوید.

کلاس های جایگزین با interface متفاوت

روش تغییر نام متد را بر روی هر تعداد متد ی که کار یکسان را با امضای متد مختلف انجام میدهند اعمال کنید. معمولا این کافی نیست و در بعضی حالات کلاس ها به اندازه کافی کار انجام نمیدهد از روش انتقال متد به قدری استفاده کنید که پروتکل ها یکسان شود. ممکن است نیاز شود به شکل اضافه کد ها را انتقال دهید تا به این هدف برسید و بعد شما میتوانید از روش استخراج کلاس پدر[1] استفاده کنید.

کلاس کتابخانه ناتمام Incomplete Library Class

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

اما ابزار هایی نیز داریم که در این موقعیت مطرح میشوند، اگر یک تعداد تابع است که آرزو می کنید کلاس کتابخانه ای شما آنها را داشت میتوانید از معرفی متد خارجی[2] استفاده کنید اگر به قابلیت های خیلی بیشتر نیاز دارید روش معرفی کنش محلی[3] را به کار ببندید.

[1] Extract Superclass
[2] Introduce Foreign Method
[3] Introduce Local Extension

مقدمه

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

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

مقدمه

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

نحوه تشخیص و معرفی راه حل مرد واسطه
یکی از فواید اصلی اشیا Encapsulation میباشد یعنی جزئیات داخلی را از بقییه اشیا مخفی کنیم Encapsulation معمولا با نوعی همراهی بوجود می آید شما از یک کارگردان میپرسید که برای یک ملاقات وقت آزاد دارد او به دفترسررسید اش رجوع میکند و دفتر سر رسید به شما یک جواب می دهد همه چیز به خوبی انجام میشود. نیازی نیست که بدانید کارگردان دفتر سررسید واقعی دارد یا از نسخه الکترونیکی استفاده میکند یا از یک منشی برای مدیریت کردن قرار ملاقات ها استفاده می کند.
اما با زیاد شدن واسطه ها و پیچ خم ها قضیه به این خوبی باقی نمی ماند. شما به interface یک کلاس نگاه می کنید و میبینید که نصف متد ها با همراهی یک کلاس دیگر در حال انجام است. بعد از چندی نیاز است که با روش حذف مرد واسطه مستقیما از خود شی بپرسیم که اوضاع از چه قرار است! اگر تعداد کمی توابع وجود دارند که کار زیادی نمیکنند از روش توابع درخط استفاده کنید تا آنها را به صدا زننده منتقل کنید. اگر یک رفتار اضافی وجود دارد میتوانید از روش جایگزینی همراهی با وراثت[1] استفاده کنید تا مرد واسطه را به یک زیرکلاس از شی واقعی تبدیل کنید این به شما کمک میکند که قابلیت ها را بدون دنبال کردن تمامی آن همراهی ها تکامل بخشید.
[1] Replace Delegation with Inheritance

مقدمه

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

نحوه تشخیص و معرفی راه حل زنجیر پیام
شما زنجیر پیام را وقتی می بینید که یک مشتری یک شی را برای یک شی دیگر طلب میکند سپس شی دیگر را طلب میکند و باز شی دیگری را طلب میکند و به این طریق شما تعداد زیادی خط به صورت getThis می بینید یا یک دنباله ای از temp ها رسیدن به این مکان به معنی استفاده بیش از حد از جهت دادن است. ( ارجاع به گرفتن شی از کلاس های دیگر)
شما میتوانید از روش پنهان سازی وکیل[1] در مکان های مختلف زنجیر استفاده کنید. اما انجام زیاد اینکار میتواند هر واسطه را به یک middle man تبدیل کند. اغلب یک روش بهتر این است که ببینیم شی ساخته شده برای چه استفاده می شود سپس میتوان با روش استخراج متد تکه هایی از کدی که استفاده می شود را برداشت و با روش انتقال متد به زنجیر های پایین منتقل کرد.
[1] Hide Delegate

مقدمه

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

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