این اصل، از یک اصلِ فلسفی بریتانیایی برداشت شده است: "سعی کنیم جهان را - به نسبت آنچه که پیش تر یافته ایم - جای بهتری کنیم".
در کتاب خواندنی "97 نکته ای که هر برنامه نویس باید بداند"، Uncle Bob با استفاده از این اصل، اصلی دیگر را در حوزه نرم افزار بیان می کند: "هر بار کدی را دیدیم، به نسبت قبل آن را بهتر کنیم." در این میان مهم نیست که کدام یک از اعضای تیم قبلا این کد را زده و یا مقدار بهبود چه حد کوچک باشد. این بهبود می تواند به کوچکی تغییر نام متغیر ها، کم کردن تکرار (duplication) ، کوتاه کردن یک متد طولانی و خواناتر کردن کد و ... باشد.
در جهان، همه هستی (اعم از نرم افزار) به طور طبیعی به ویرانی و آشوب و فرسودگی میل می کند و برای جلوگیری از این امر ما باید انرژی مصرف کنیم و تعهد داشته باشیم. در نرم افزار هم وقتی همه اعضای تیم به این اصل متعهد باشند، ساختار کد به جای هرز رفتن در گذر زمان، روز به روز و به تدریج بهتر خواهد شد.
همانطور که آشغال ریختن در طبیعت، عملی خلاف شعور و فرهنگ می باشد، این اصل بیان می کند که اصلاح نکردن کد در صورت مشاهده ایراد و ضعف به همان میزان دور از فرهنگ و تعهد و حرفه ای گری است. قرار نیست فقط به کد های خودمان اهمیت بدهیم و نسبت به آن ها حساس باشیم. هر کدام از اعضای تیم باید نسبت به کیفیت کار کل تیم حساس بوده و سعی در بهبود داشته باشند.
1.یادداشت عمو باب در مورد اصل پیشاهنگی
http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule
2. در مقاله "ریفکتورینگ فرصت طلبانه"، مارتین فاولر توضیح می دهد که چطور علی رغم وجود دوره هایی برای اصلاح ساختاری سیستم، باید تیم همواره و هر جا و هر زمانی نسبت به ریفکتورینگ و اصلاح کد تعهد داشته باشد. در اینجا فاولر فرصت های متعددی را که در حین کار با کد های سیستم پیش می آید، مطرح می کند و هر کدام را به عنوان فرصتی برای ریفکتورینگ مغتنم می شمارد. فاولر معتقد است ریفکتورینگ یک امر و اصل همیشگی و جاری در سیستم باید باشد.اگر با تیمی مواجه هستیم که همیشه برای اصلاح کد ها نیاز به برنامه ریزی و جلسات متعدد دارد، یک جای کار می لنگد!.
https://martinfowler.com/bliki/OpportunisticRefactoring.html
