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

مقدمه

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

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

مقدمه

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

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

مقدمه

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

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

مقدمه

پیش از این راجع به 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 یا بازآرایی چیست؟

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

ادامه مطلب