بایگانی

بایگانی آبان

اصل (DRY (Don’t Repeat Yourself

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

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

 اما یک دلیل که فکر کنم ریشه روانشناسی هم داشته باشد در سالهای اول دانشگاه بوجود می آید و بعدها بعضی ها نمی توانند ترک کنند. شاید جملاتی مانند این که پروژه من چند هزار سطر شد و یا شبیه آن برای خیلی از دوستان آشنا باشد. جملاتی که در ترمهای اول دانشگاه تکرار می شود و تعداد سطرها بدون توجه به هر اصل دیگر، عامل اصلی برتری یک پروژه در بین گروه خاص از دانشجویان می شود. و سپس بعضی از دوستان نمی توانند از دام این عامل برتری خلاص شوند. و اغلب مشکلاتی که بخاطر این مسئله در برنامه هایشان بوجود می آید را با جملاتی مانند اینکه پروژه در این حجم (از لحاظ تعداد سطرها) نگهداریش واقعا مشکل و کار هر کسی نیست و … را تکرار می کنند. و صدها دلیل کوچک و بزرگ می توان پیدا کرد که می تواند عامل مشکل بالا باشد. اما برای رفع این مشکل بد نیست که یک اصل را به نام DRY (Don’t Repeat Yourself ) را مرور کنیم.

تعریف اصلی DRY

DRY: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

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

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

class Line {

public:

Point start;

Point end;

double length;

};

تکه کد بالا را در نظر بگیرید، فکر می کنید مشکلی روی این کد وجود دارد یا نه. شاید در نگاه اول این کد مشکل نداشته باشد اما در این تکه کد اصل DRY رعایت نشده است. صفت length را در نظر بگیرید، مقدار این صفت با توجه به مقادیر start و end محاسبه می شود و با تغییر هر کدام از این صفات، آن نیز تغییر می کند (همیشه این نوع تکرار کد را با افزونگی در پایگاه داده مقایسه می کنم و می کویم صفتی که  قابل محاسبه از روی صفات دیگر باشد، نیازی به ذخیره سازی ندارد. می شود نرمالسازی در پایگاه داده را مفهومی مشابه این اصل دانست). پس بهتر است این تکه کد به صورت زیر تغییر کند.

class Line {

public:

Point start;

Point end;

double length() { return start.distanceTo(end); }

};

 

می توانیم به سادگی راه حل های زیادی برای رهایی از این دام پیدا کنیم و فکر می کنم نیاز زیادی به بحث روی این موضوع نیست، البته پیشگیری مثل همیشه بهترین شیوه درمان است. اما دوست دارم ادعای جالبی که آقایان  Andy Hunt و  Dave Thomas(اصل DRY، برای اولین با توسط این دو نفر ارائه شده است.) رابیان کنم و دوست دارم نظر شما را در مورد این ادعا بدانم. به نظر شما مرحله نگهداری یک برنامه  از چه زمانی شروع می شود؟ نمی دانم دقیقا پاسخ شما چیست، اما پاسخ دو نفر بالا به این صورت است که برنامه نویسان همیشه در مرحله نگهداری هستند.  و تنها در ۱۰ دقیقه اول یعنی زمانیکه شما برای اولین با یک تکه کد را تایپ می کنید در مرحله نگهداری قرار ندارید و سپس شما بارها و بارها یک تکه کد را تغییر می دهید تا به هدف خود برسد و اینها جزء مرحله نگهداری هستند. حال نظر شما چیست؟

Categories: Agile, شي گرايي, طراحي Tags:

بدون شرح

 آن که دیگران را می شناسد، خردمند است.

آن که خود را می شناسد، روشنیده است.

آن که بر دیگران پیروز می شود، نیرومند است.

آن که بر خود پیروز می شود، نیرومند است.

آن که شادی را می شناسد، ثروتمند است.

آن که بر راه خویش پا بر جا می ماند، با اراده است.

 

فروتن باش، و اما غرور خویش را حفظ کن.

خم شو، اما سرافراز بمان.

خود را خالی کن، و اما سرشار بمان.

خود را بفرسای، اما تازه بمان.

 

خردمند خود را به نمایش نمی گذارد، و از این راه می درخشد.

خود نمایی نمی کند، و بنابراین او را می بینند.

خود را ستایش نمی کند، و بنابراین سزاوار است.

و از آن جا که رقابت نمی کند، هیچ کس را در جهان یارای رقابت با او نیست.

Categories: غیرفنی Tags: