بایگانی

نوشته های برچسب زده شده ‘Refactoring’

قانون بوی اسکات

۲۴ مرداد ۱۳۹۳ ۱ دیدگاه

اکثر چیزهای جدیدی که می‌خریم و یا هدیه می‌گیریم یک خاصیت مشترک دارند، در روزها و هفته‌های اول شدیدا هواسمان بهش هست و به شدت مواظبش هستیم. اما به مرور زمان از میزان این حساسیت کاسته می‌شود. در توسعه نرم‌افزار نیز همین روند تکرار می‌شود، در هفته‌های اول توسعه یک نرم‌افزار جدید حساسیت ویژه‌ای به به طراحی ساده و نوشتن کدهای تمییز و Refactoring پیوسته داریم، اما به مرور و با افزایش پیچیدگی و فشارها از میزان این حساسیت کاسته می‌شود و میزان کیفیت داخلی نرم‌افزار کاهش می‌یابد. اما ما به عنوان یک توسعه‌دهنده وظیفه داریم تا کد خود را در طول زمان تمیز نگهداری کنیم.

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

تئوری پنجره شکسته

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

به‌صورت اتفاقی در جای مطلبی را می‌خواندم که در آن اشاره به تئوری پنجره شکسته داشت. تئوری پنجره شکسته محصول فکری دو جرم شناس آمریکائی (Criminologist) بود به اسامی جمس ویلسون (James Wilson) و جورج کلینگ(George Kelling).  این دو استدلال می کردند که جرم نتیجه یک نابسامانی است. اگر پنجره ای شکسته باشد و مرمت نشود آنکس که تمایل به شکستن قانون و هنجارهای اجتماعی را دارد با مشاهده بی تفاوتی جامعه به این امر دست به شکستن شیشه دیگری می زند. دیری نمی پاید که شیشه های بیشتری شکسته می شود و این احساس آنارشی و هرج و مرج از خیابان به خیابان و از محله ای به محله دیگر می رود و با خود سیگنالی را به همراه دارد از این قرار که هر کاری را که بخواهید مجازید انجام دهید بدون آنکه کسی مزاحم شما شود.

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

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