آشنایی با قانون DRY

در حوزه ی توسعه ی نرم افزار، اصول و قواعد بسیاری وجود دارد که گاها یکی از دیگری مهم‌تر جلوه می‌کند اما یکی از اساسی‌ترین قواعد برنامه نویسی، قانون DRY است که مخفف واژگان Don't Repeat Yourself به معنی«دوباره کاری نکن» است!

این قانون توسط دو توسعه‌دهنده به نام های Andy Hunt و Dave Thomas ابداع شد که بسیاری از دیزاین پترن های معروف برنامه نویسی، ریشه در این قانون دارند.

برنامه نویسی که بتواند تشخیص دهد کدام بخش‌های کد اصطلاحاً Duplicate یا «مشابه» هستند و تمام تلاش خود را به کار بندد تا با استفاده از کلاس‌ها و فانکشن های مختلف، میزان استفاده از کدهای تکراری در سراسر برنامه را به حداقل برساند، در نهایت سورس کد تمیز تری تحویل خواهد داد که در آینده نگهداری چنین پروژه یی به مراتب راحت‌تر از سورس کدی است که پر است از کدهای مشابه!

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

در فرایند توسعه ی نرم افزار، بخش‌های بسیاری از کد را می‌توان دید که تکراری هستند و قانون DRY دقیقاً برای چنین موقعیت هایی است. شما به عنوان یک توسعه‌دهنده ی حرفه یی، همواره باید این ذهنیت را داشته باشید که در نرم افزاری که می نویسید -خواه یک اپ موبایل باشد و خواه یک سایت- صرفاً از یک راه باید بتوان کار خاصی را انجام داد (مثلاً ارتباط با دیتابیس) و این راه‌کار باید تا حد ممکن ساده، ایمن و اثربخش باشد.

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

به طور مثال، اگر آبجکتی داریم که «عملکردها و رفتارهای» متنوعی از آن انتظار می رود، به جای استفاده از دستورات شرطی if برای هندل کردن چنین موقعیت هایی، چنین عملکردها و رفتارهایی را می‌توان با استفاده از دیزاین پترن Strategy عملی ساخت.

علاوه بر دیزاین پترن ها، یکسری اصول کدنویسی که تحت عنوان SOLID شناخته می‌شوند نیز بر پایه ی اصل DRY هستند (برای آشنایی بیشتر با مفهوم SOLID، به آموزش آشنایی با قوانین پنج گانهٔ SOLID مراجعه نمایید.) به طور مثال، حرف S در ابتدای SOLID به اصطلاح Single Responsibility اشاره دارد. به عبارت دیگر، هر کلاسی که در پروژه ی خود ایجاد می‌کنیم فقط و فقط باید مسئول یک کار باشد و در صورت نیاز به اعمال تغییرات در کلاس مد نظر، فقط و فقط باید یک دلیل برای ایجاد آن تغییر وجود داشته باشد نه اینکه کلاس مد نظر در جای جای نرم‌افزار برای کارهای مختلفی استفاده شده باشد و به هر دلیلی، نیاز به اعمال تغییرات در آن کلاس داشته باشیم.

به عنوان مثالی دیگر، حرف O در SOLID به اصلی تحت عنوان Open/Closed Principle اشاره دارد. این اصل حاکی از آن است که کدی که می نویسید باید «امکان توسعه یافتن را به برنامه نویسان دیگر بدهد اما تحت هیچ عنوان امکان ایجاد تغییر در کدهای قبلی را ندهد.» چنین اصلی این تضمین را ایجاد می‌کند که نرم‌افزار در فرایند توسعه و تکمیل با این مشکل مواجه نخواهد شد که برنامه نویس دیگری بیاید، بخش‌هایی را تغییر دهد غافل از اینکه این اعمال تغییرات، منجر به ایجاد خرابی در سایر بخش‌های نرم‌افزار شده است.

به طور کلی، مد نظر داشتن قانون DRY در توسعه ی نرم افزار، راه‌کاری است که از آن طریق می‌توان برنامه‌هایی اصولی تر، ساده تر، بدون باگ تر، قابل نگهداری تر و مهم‌تر از همه، باکیفیت تر نوشت؛ البته هرگز فراموش نکنیم که گاهی اوقات شرایطی برای توسعه‌دهنده پیش می‌آید که مجبور به تکرار کد است -مثلا در فرایند Denormalization دیتابیس- که در چنین شرایطی دوباره کاری اصلاً مشکلی ندارد!

به خاطر داشته باشید در کار با دیتابیس یا پایگاه داده، Denormalization به فرایندی گفته می‌شود که از آن طریق توسعه‌دهنده سعی می‌کند پرفورمنس یا عملکرد فراخوانی داده‌ها از دیتابیس را با اضافه کردن داده‌های تکراری یا اضافی و همچنین گروه بندی کردن داده‌ها ارتقاء بخشد. نقطه ی مقابل این فرایند، Normalization قرار دارد که تمرکزش بر کاهش هرچه تمام تر داده‌های اضافی و تکراری در دیتابیس است.