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

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

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

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