دو دوست در حال پیاده‌روی در یک جاده بودند که ناگهان با حصاری در وسط راه مواجه شدند، اولی که روحیه اصلاح‌گری بالایی داشت با خوشحالی گفت: این حصار اینجا بی استفاده‌ست، بیا بذاریمش کنار. دوست دوم که کمی باهوش تر بود جواب داد: اگر استفادهٔ این حصار رو نمی‌بینی پس من اجازه نمی‌دم که برش داری، برو کنار و کمی فکر کن، هر موقع استفادهٔ این رو فهمیدی و به من گفتی اونوقت شاید اجازه بدم این رو از سر راه برداری.
دوست دوم راست می‌گفت حصار که از درون زمین سبز نشده بود، در واقع کسی آن را با قصد قبلی آنجا گذاشته بود، شاید اگر اولی کمی دورتر از نوک دماغش را نگاه می‌کرد و از حصار فاصله می‌گرفت با یک چاله یا خطر دیگری رو به رو می‌شد. پس باید اول دلیل بودن حصار را پیدا می‌کرد.
حصار چسترتون (Chesterton's fence) اصلی است که در آن اصلاحات نباید انجام شود مگر این که استدلال‌های پشت وضعیت فعلی امور فهمیده شده باشد. این اصل در حوزه‌های مختلفی مثل سیاست، اقتصاد، نو اندیشی دینی و ... قابل تعمیم است، ویکیپدیا معمولا کاربران خود را به رعایت این اصل در زمان ویرایش صفحات توصیه می‌کند.
گیلبرت چسترتون نویسنده، فیلسوف و منتقد قرن ۱۹ و ۲۰ انگلیس است که بخشی از کتابش به نام The Thing: Why I Am a Catholic که در سال ۱۹۲۹ چاپ شد به نام اصل حصار چسترتون معروف شده است.
به عنوان توسعه دهنده نرم افزار وقتی وارد یک پروژه بزرگ می‌شویم با کدهای زیادی رو به رو می‌شویم که نویسنده اصلی آنها نبوده‌ایم به خصوص اگر Code Base پروژه نسبتا قدیمی باشد. در این مواقع ناخودآگاه به دنبال قسمت‌های غلط یا بد کد می‌گردیم تا آنها را اصلاح کنیم و ناگهان این جمله‌ها در ذهن و زبان ما جاری می‌شود:
چرا این تکه کد اینجاست! باید ببرمش بالاتر!
چرا این شرط را دوبار چک کرده، اضافیه پاکش کنم!
این تکه رو که خیلی راحت‌تر می شد نوشت! چرا این کار رو کرده؟!
اوه این فاجعه‌ست! اگه من بودم یه جور دیگه می‌نوشتم.
و چرا های مختلف دیگر...
این چرا ها معمولا زمانی پیش می‌آید که هنوز تسلط کاملی روی جزییات کد نوشته شده نداریم. راحت ترین کار این است که فرض کنیم برنامه نویس قبلی بسیار ضعیف‌تر از ما بوده و مساله را به طور کامل متوجه نشده است. با این که این امر فرض محالی نیست و احتمال آن وجود دارد، اما باید این را بدانیم که دقیقا عکس این موضوع نیز محتمل است و ممکن است همه تصمیم‌ها با دقت و دلیل خاصی گرفته شده باشند، برای همین چالش ما تلاش برای پیدا کردن این دلیل‌ها است. فهمیدن حالت ذهنی کسی که این کدها را در یک زمان مشخص نوشته هم کار چالش برانگیزی است.
هر نسلی خود را باهوش تر از نسل قبل و خردمندتر از نسلی که بعد از او می آید، تصور می‌کند.
جورج اورول
بنابراین نرم افزار درون خلا طراحی و تولید نمی‌شود، بلکه محصول دنباله‌ای از عوامل، رخدادها و تعاملات پیچیده است. اگر یک مانع وجود دارد لابد دلیلی برای قرار گرفتن آن هست و اگر کدی وجود دارد لابد دلیلی پشت آن هست.
اصل حصار چسترتون در مهندسی نرم افزار می‌گوید ما تنها زمانی اجازه تغییر کدهای موجود را داریم که استدلال‌های پشت آن را کاملا فهمیده باشیم و بدانیم که چرا به این شکل نوشته شده‌اند، در غیر این صورت هر تغییری با ریسک ایجاد عوارض جانبی و مشکلات پیش بینی نشده همراه خواهد بود.
برای فهمیدن استدلال‌های پشت بخش‌هایی از کد که در مورد آن سوال داریم ساده‌ترین راه این است که به برنامه نویس اصلی مراجعه کنیم، اگر برنامه‌نویس اصلی در دسترس باشد این پرسش‌ها باعث می‌شود که او نیز دلایل خود را دوباره مرور کند و به درستی تصمیم‌های خود مطمن‌تر شود که بسیار برای پروژه مفید است اما ممکن است برنامه نویس اصلی دیگر در شرکت حضور نداشته باشد. یا ممکن است که هنوز در آن شرکت باشد ولی به دلیل گذر زمان یا حضور در پروژه دیگر دلایل کارهای خود را فراموش کرده باشد.
در این صورت بهترین راه این است که کدها را با دقت مطالعه و Debug کنیم و دلایل را حدس بزنیم، چون حدس زدن بهتر از نداشتن دلیل است و حداقل چهارچوبی برای تغییرات پیشنهادی داریم. همچنین داشتن چندین حدس خیلی بهتر از یک حدس است چون باعث پوشش بیشتر سناریوهای محتمل می‌شود.
منابع زیر نیز می‌توانند به ما در فرآیند فهمیدن کدها کمک کنند:
البته باید مراقب بود که حصار چسترسون تبدیل به مانعی برای محافظه‌کاری و مقاومت در مقابل تغییرات نشود، همان طور که از اسم نرم افزار پیداست باید به همان اندازه هم نرم و انعطاف پذیر باشد تا بتواند هر زمان که لازم بود تغییر کند، ولی تغییرات باید با پشتوانه‌های منطقی و صحیح انجام شود.
در آخر باید گفت که ما باید قبل از تلاش برای برچیدن یا تغییر حصار تلاشی را صرف دیدن استفادهٔ حصار کنیم در غیر این صورت ریسک ضررهای بیشتر نسبت به فواید آن را خواهیم داشت.
