این چیز چرا اینجاست؟
نرده‌ی چسترتون و مسئله‌ای که دیگر دیده نمی‌شود
گاهی درخواست اضافه‌کردن چیزی نیست:
«این قانون را حذف کنیم.»
«این مرحله‌ی اضافی را برداریم.»
«این قطعه‌ی قدیمی کد را پاک کنیم.»
درخواست معقولی است. چیزی جلوی ما را گرفته، هزینه دارد، و هیچ‌کس هم کاربردش را نمی‌فهمد.
پیش از موافقت، فقط یک سؤال بنویسید.
چه می‌پرسید؟
نرده‌ای در میان راه
چسترتون در سال ۱۹۲۹ مثالی از نرده یا دروازه‌ای در میان یک راه زد.
اصلاح‌گری به آن می‌رسد و می‌گوید:
«کاربردش را نمی‌فهمم. برداریمش.»
اما پاسخ عاقلانه چیزی شبیه این است:
اگر کاربردش را نمی‌فهمی، هنوز برای برداشتنش آماده نیستی. اول بفهم چرا کسی آن را ساخته است؛ بعد شاید بهترین کار واقعاً خراب‌کردنش باشد.
امروز این ایده را معمولاً نرده‌ی چسترتون می‌نامند.
سؤال کوتاهش این است:
این چیز در ابتدا راه‌حل چه مسئله‌ای بوده است؟
اما چرا این سؤال مهم است؟
مشکل راه‌حل‌های موفق این است که مسئله را پنهان می‌کنند
فرض کنید در یک تیم قانونی هست:
چهارشنبه‌ها استقرار نداریم.
برای کسی که تازه به تیم آمده، قانون احمقانه به نظر می‌رسد.
چرا چهارشنبه با سه‌شنبه فرق دارد؟
خط لوله‌ی استقرار خودکار است. تست داریم. چهارشنبه هم روز کاری است. این قانون فقط باعث می‌شود تغییرهای آماده تا شنبه معطل بمانند.
پس حذفش کنیم.
اما کمی در تاریخچه می‌گردیم.
دو سال پیش تیم کوچک‌تر بوده است. استقرارها دستی بوده‌اند. بازگشت به نسخه‌ی قبل دشوار بوده و آخر هفته کسی کشیک نداشته است. یک چهارشنبه عصر نسخه‌ای منتشر شده، سایت چند ساعت بعد خراب شده و مشکل تا صبح شنبه درست نشده است.
بعد از آن حادثه قانون آمده:
چهارشنبه استقرار نکنید.
حالا قانون دیگر تصادفی به نظر نمی‌رسد.
اما نکته‌ی مهم‌تر این است:
تا وقتی قانون کار می‌کند، حادثه‌ای که از آن جلوگیری می‌کند دیده نمی‌شود.
اگر نرده خوب کار کند، پشت آن خبری نیست.
همین می‌تواند باعث شود چند سال بعد کسی بگوید:
«من که هیچ‌وقت ندیده‌ام اینجا مشکلی پیش بیاید. پس نرده چه فایده‌ای دارد؟»
شاید مشکلی نمی‌بینیم چون نرده آن‌جاست.
خودِ نرده مسئله نیست
حالا که دلیل قانون چهارشنبه را فهمیدیم، آیا باید آن را برای همیشه نگه داریم؟
نه.
اینجا یک قدم دیگر لازم است.
قانون قدیمی می‌گوید:
چهارشنبه استقرار نکن.
اما مسئله‌ی زیر آن شاید این بوده:
اگر استقرار خراب شد، باید کسی بتواند سریع متوجه شود و آن را برگرداند.
این دو یکی نیستند.
اولی یک راه‌حل است.
دومی چیزی است که باید درست بماند.
حالا فرض کنید امروز تیم:
- استقرار خودکار دارد؛
- تست‌های بیشتری دارد؛
- خطاها را سریع پایش می‌کند؛
- بازگشت به نسخه‌ی قبل چند دقیقه طول می‌کشد؛
- و آخر هفته کشیک دارد.
مسئله‌ی قدیمی شاید هنوز وجود داشته باشد: استقرار هنوز می‌تواند خراب شود.
اما راه‌حل قدیمی دیگر تنها پاسخ آن نیست.
می‌شود قانون را عوض کرد:
استقرار وقتی مجاز است که کسی مسئول پایش باشد و راه بازگشت سریع داشته باشیم.
چهارشنبه دیگر مهم نیست.
چیزی که مهم بود امکان بازیابی بود.
از راه‌حل قدیمی به چیزی که باید درست بماند
این حرکت شاید مهم‌ترین بخش نرده‌ی چسترتون باشد.
فقط نپرسید:
چرا این قانون ساخته شد؟
بپرسید:
این قانون قرار بود چه چیزی را درست نگه دارد؟
مثلاً:
«چهارشنبه استقرار نکن.»
شاید قرار بوده این درست بماند:
اگر انتشار خراب شد، کسی برای بازیابی حاضر باشد.
«بازپرداخت بالای یک مبلغ مشخص باید دو امضا داشته باشد.»
شاید قرار بوده این درست بماند:
یک اشتباه یا سوءاستفاده‌ی بزرگ نتواند با تصمیم یک نفر اتفاق بیفتد.
«اگر نسخه‌ی کاربر کمتر از X بود، این مسیر قدیمی را اجرا کن.»
شاید قرار بوده این درست بماند:
کاربران نسخه‌های قدیمی هنوز بتوانند از سرویس استفاده کنند.
«این فیلد باید در فرم باقی بماند.»
شاید قرار بوده این درست بماند:
پیش از انجام کار، اطلاعاتی که برای یک الزام قانونی یا مالی لازم است ثبت شده باشد.
وقتی از نرده به چیزی که نرده محافظت می‌کند برسیم، فضای راه‌حل‌ها دوباره باز می‌شود.
سه سرنوشت برای یک نرده
وقتی دلیل چیزی را پیدا کردیم، همیشه به یک نتیجه نمی‌رسیم.
دست‌کم سه حالت وجود دارد.
۱. مسئله هنوز هست و نرده هنوز راه‌حل خوبی است
مثلاً دو امضا هنوز واقعاً جلوی خطای پرهزینه‌ای را می‌گیرد و جایگزین بهتری هم نداریم.
در این حالت، نرده را نگه می‌داریم.
اما این بار می‌دانیم چرا.
۲. مسئله هنوز هست، ولی نرده دیگر بهترین راه‌حل نیست
مشکل استقرار نامطمئن هنوز وجود دارد، اما امروز پایش، کشیک و بازگشت خودکار داریم.
در این حالت نرده را جایگزین می‌کنیم.
این حالت مهم است، چون سؤال فقط این نیست:
نگه داریم یا حذف کنیم؟
گزینه‌ی سومی هم هست:
چه چیزی می‌تواند همان کار را بهتر انجام دهد؟
۳. خود مسئله دیگر وجود ندارد
شاید آخرین کاربر نسخه‌ی قدیمی سال‌ها پیش مهاجرت کرده است.
شاید قانونی که فرم برایش اطلاعاتی جمع می‌کرد تغییر کرده است.
شاید سامانه‌ی دیگری اکنون همان خطا را خودکار می‌گیرد.
در این حالت می‌توان نرده را برداشت.
نه چون کاربردش را نفهمیدیم؛
بلکه دقیقاً چون فهمیدیم چه کاربردی داشته و می‌دانیم دیگر لازم نیست.
و گاهی نرده از اول هم خوب نبوده است
نرده‌ی چسترتون یک فرض خطرناک هم می‌تواند بسازد:
هر چیز قدیمی حتماً دلیل خوبی داشته است.
نه.
بعضی چیزها نتیجه‌ی تصمیم بد بوده‌اند.
بعضی موقتی بوده‌اند و کسی یادش رفته پاکشان کند.
بعضی از روی تقلید آمده‌اند.
بعضی برای شرایطی ساخته شده‌اند که حتی آن زمان هم درست فهمیده نشده بود.
و بعضی فقط حادثه‌ی تاریخی‌اند: کسی یک بار چیزی را اضافه کرده و بعد همه فرض کرده‌اند حتماً لازم است.
پس:
«نمی‌دانم چرا اینجاست» دلیل خوبی برای حذف نیست.
اما برعکسش هم درست است:
«حتماً دلیلی داشته» دلیل خوبی برای نگه‌داشتن نیست.
ندانستن باید ما را به تحقیق برساند، نه به حفظ ابدی.
وقتی هیچ‌کس نمی‌داند
گاهی همه‌ی تاریخچه را می‌گردیم و باز هم چیزی پیدا نمی‌کنیم.
هیچ‌کس نمی‌داند این مرحله چرا هست.
آیا باید تا ابد نگهش داریم؟
نه.
در این حالت مسئله از فهمیدن گذشته به آزمایش‌کردن حال تبدیل می‌شود.
پیش از حذف بپرسید:
اگر این چیز واقعاً کاری انجام می‌دهد، با حذفش انتظار دارم چه چیزی خراب شود؟
بعد تا جای ممکن حذف را به یک آزمایش برگشت‌پذیر تبدیل کنید.
مثلاً:
- قانون را ابتدا برای گروه کوچکی کنار بگذارید؛
- یک مرحله را موقتاً حذف کنید و نتیجه را اندازه بگیرید؛
- تغییر را طوری منتشر کنید که بازگشت سریع باشد؛
- پیش از تغییر مشخص کنید چه علامتی یعنی باید برگردیم.
در کد، اگر تاریخچه‌ی نسخه‌ها و بازگشت مطمئن داریم، حتی حذف کامل می‌تواند برگشت‌پذیر باشد. لازم نیست تکه‌های خاموش و مرده‌ی کد را برای همیشه «احتیاطاً» نگه داریم.
اصل مهم‌تر این است:
راه برگشت را پیش از برداشتن نرده بشناس.
یک ماه اتفاقی نیفتاد؛ آیا نرده بی‌فایده بود؟
اینجا یک دام دیگر هست.
فرض کنید قانونی برای جلوگیری از اتفاقی ساخته شده که سالی یک بار رخ می‌دهد.
آن را یک ماه حذف می‌کنیم.
هیچ اتفاقی نمی‌افتد.
آیا ثابت شد قانون بی‌فایده بوده؟
نه.
اگر اتفاق نادر باشد، نبودنش در یک بازه‌ی کوتاه چیز زیادی به ما نمی‌گوید.
این مشکل مخصوص نرده‌هاست: خیلی وقت‌ها کاری که انجام می‌دهند جلوگیری از یک رخداد است، و چیزی که جلویش گرفته شده دیده نمی‌شود.
پس پیش از آزمایش بپرسید:
مسئله‌ای که این نرده می‌گیرد معمولاً هر چند وقت یک بار ممکن است رخ دهد؟
و:
آیا می‌توانم نشانه‌ای زودتر از خود حادثه اندازه بگیرم؟
مثلاً به‌جای منتظرماندن برای یک خسارت واقعی، شاید بتوانیم تعداد خطاهای نزدیک به حادثه، هشدارها یا شرایط خطرناک را بسنجیم.
نرده‌ها هم هزینه دارند
تا اینجا شاید به نظر برسد که برگه جانب نرده‌ها را گرفته است.
اما نرده‌ها رایگان نیستند.
یک قانون قدیمی ممکن است:
- کار را کند کند؛
- پیچیدگی بسازد؛
- استثنا پشت استثنا ایجاد کند؛
- افراد تازه را گیج کند؛
- جلوی تغییرهای مفید را بگیرد؛
- یا خودش منبع خطا شود.
یک تکه کد قدیمی هم هزینه دارد، حتی اگر اجرا نشود: باید خوانده شود، فهمیده شود، تست شود و با تغییرهای آینده کنار بیاید.
پس نرده‌ی چسترتون نمی‌گوید:
چیزهای قدیمی را دست نزن.
می‌گوید:
هزینه‌ای را که می‌بینی، با فایده‌ای که هنوز نفهمیده‌ای مقایسه نکن.
اول فایده را پیدا کن.
بعد می‌توانی درباره‌ی هزینه و فایده تصمیم بگیری.
یک پرسش بهتر از «حذفش کنیم؟»
فرض کنید کسی می‌گوید:
«چهارشنبه‌ها استقرار نکنیم» دیگر مزخرف است.
دو پاسخ ساده داریم:
«باشه، حذفش کنیم.»
یا:
«نه، این قانون قدیمی است؛ حتماً حکمتی داشته.»
هیچ‌کدام خیلی خوب نیست.
می‌شود سؤال را عوض کرد:
این قانون چه خطری را مهار می‌کرد، و امروز برای مهار همان خطر چه چیزی لازم داریم؟
حالا شاید پاسخ این شود:
خطر: خراب‌شدن انتشار در زمانی که کسی برای بازیابی نیست.
و تصمیم تازه:
انتشار در هر روزی مجاز است، اگر پایش فعال باشد، مسئول بازیابی مشخص باشد و بازگشت سریع ممکن باشد.
نه نرده‌ی قدیمی را بی‌فکر نگه داشتیم و نه بی‌فکر برداشتیم.
مسئله را نگه داشتیم و راه‌حل را دوباره طراحی کردیم.
یک روش کوتاه برای روبه‌روشدن با نرده‌ها
وقتی با قانون، فرایند، ویژگی یا تکه‌کدی روبه‌رو شدید که کسی می‌خواهد حذفش کند، این مسیر را امتحان کنید.
۱. نرده دقیقاً چه می‌کند؟
پیش از بحث درباره‌ی دلیلش، خود رفتار فعلی را دقیق بفهمید.
۲. چه مسئله‌ای باعث ساخته‌شدنش شد؟
دنبال حادثه، نیاز، محدودیت یا خطری بگردید که پیش از آن وجود داشته است.
۳. قرار بود چه چیزی درست بماند؟
راه‌حل را از چیزی که محافظت می‌کند جدا کنید.
چه چیزی بعد از حذف نرده هم باید همچنان درست باشد؟
۴. آن مسئله هنوز وجود دارد؟
ممکن است شرایط عوض شده باشند.
۵. اگر هنوز هست، آیا نرده بهترین راه‌حل آن است؟
شاید بتوان همان محافظت را ساده‌تر، ارزان‌تر یا مطمئن‌تر ایجاد کرد.
۶. اگر مطمئن نیستیم، چطور امن آزمایش کنیم؟
چه چیزی را اندازه می‌گیریم؟
چه علامتی نشان می‌دهد اشتباه کرده‌ایم؟
چطور برمی‌گردیم؟
چه وقت به‌اندازه‌ی کافی فهمیده‌ایم؟
لازم نیست تاریخ کامل هر خط کد یا هر قانون سازمان را بنویسیم.
برای تصمیم‌گیری معمولاً وقتی به‌اندازه‌ی کافی جلو رفته‌ایم که بتوانیم سه جمله را کامل کنیم:
این چیز ساخته شد چون…
چیزی که قرار بود درست نگه دارد این بود که…
امروز برای درست نگه‌داشتن همان چیز، تصمیم ما این است که…
اگر جمله‌ی اول را نمی‌توانیم پر کنیم، هنوز تاریخچه را نمی‌فهمیم.
اگر دومی را نمی‌توانیم پر کنیم، شاید راه‌حل را دیده‌ایم اما مسئله را نه.
و اگر سومی را نمی‌توانیم پر کنیم، هنوز تصمیم نگرفته‌ایم؛ فقط گذشته را مطالعه کرده‌ایم.
اکنون باید چه چیزی با شما بماند؟
چیزهای قدیمی گاهی بی‌دلیل به نظر می‌رسند، دقیقاً چون در حل مسئله‌شان موفق بوده‌اند.
پس پیش از حذف یک راه‌حل قدیمی بپرسید:
این چیز اول برای چه مسئله‌ای ساخته شد؟
اما همان‌جا متوقف نشوید:
آن مسئله هنوز هست؟
و اگر هست:
آیا هنوز به همین راه‌حل نیاز داریم؟
هدف نرده‌ی چسترتون حفظ نرده نیست.
هدف این است که وقتی نرده را برمی‌داریم، چیزی را که پشت آن محافظت می‌شد ناخواسته از دست ندهیم.
تمرین‌ها
تمرین ۱ — چرا دو امضا؟
در یک شرکت قانونی وجود دارد:
«هر بازپرداخت بالاتر از مبلغ مشخصی باید به تأیید نفر دوم برسد.»
این مرحله کار را کند می‌کند و بیشتر درخواست‌ها هم بدون هیچ تغییری تأیید می‌شوند.
کسی پیشنهاد می‌دهد آن را حذف کنیم.
پیش از تصمیم، دست‌کم سه مسئله‌ی متفاوت بنویسید که ممکن است این قانون برای حل یکی از آن‌ها ساخته شده باشد.
مثلاً آیا هدفش جلوگیری از اشتباه بوده؟ تقلب؟ الزام حسابرسی؟ چیز دیگری؟
برای هر پاسخ، حذف قانون چه معنای متفاوتی پیدا می‌کند؟
فرض کنید معلوم شود قانون بعد از یک بازپرداخت اشتباه و بسیار بزرگ اضافه شده است.
مسئله را این‌طور بازنویسی کنید:
«بازپرداخت بزرگ نباید با یک اشتباه ساده انجام شود.»
حالا آیا «تأیید نفر دوم» تنها راه‌حل این مسئله است؟
سه راه دیگر پیدا کنید که شاید همان محافظت را با اصطکاک کمتری ایجاد کنند.
تمرین ۲ — یک نرده‌ی واقعی
یک قانون، مرحله، ویژگی یا تکه کد پیدا کنید که در کار شما قدیمی و دست‌وپاگیر به نظر می‌رسد.
چهار چیز را بنویسید:
- این نرده امروز چه می‌کند؟
- برای حل چه مسئله‌ای ساخته شده بود؟
- چه چیزی قرار بود با وجود آن درست بماند؟
- آن مسئله امروز در کدام‌یک از این سه حالت است؟
هنوز هست و نرده هنوز خوب است.
هنوز هست ولی راه‌حل بهتری داریم.
دیگر وجود ندارد.
اگر پاسخ را نمی‌دانید، بنویسید برای فهمیدنش کجا باید بگردید.
تمرین ۳ — نرده را امن بردارید
یکی از نرده‌هایی را که احتمال می‌دهید دیگر لازم نباشد انتخاب کنید.
پیش از حذف، این چهار جمله را کامل کنید:
اگر درباره‌ی کاربردش اشتباه کرده باشم، احتمالاً این اتفاق می‌افتد: …
اولین علامتی که می‌توانم ببینم این است: …
برای دیدن آن این چیز را اندازه می‌گیرم: …
اگر اشتباه کرده باشم، این‌طور برمی‌گردم: …
حالا حذف نرده دیگر فقط یک تصمیم نیست؛ یک آزمایش است.
تمرین ۴ — برای نفر بعد نرده نسازید
چیزی را پیدا کنید که خودتان اخیراً به کد، محصول یا یک فرایند اضافه کرده‌اید.
جایی مناسب یک توضیح کوتاه باقی بگذارید که به نفر بعد بگوید:
این چیز چه مسئله‌ای را حل می‌کند؟
نه اینکه فقط بگوید چگونه کار می‌کند.
مثلاً یک کامنت مثل:
«این شرط را حذف نکن.»
تقریباً بی‌فایده است.
اما این:
«این شرط برای کاربرانی است که نسخه‌های پیش از X هنوز این فیلد را نمی‌فرستند.»
به نفر بعد اجازه می‌دهد روزی بفهمد چه وقت می‌تواند با خیال راحت آن را حذف کند.
دفترچه‌ی مسئله
برای این برگه سه خط به دفترچه اضافه کنید:
این چیز اول برای چه مسئله‌ای ساخته شده بود؟
چه چیزی قرار بود با وجود آن درست بماند؟
و بعد:
آن مسئله هنوز هست، و اگر هست آیا هنوز به همین راه‌حل نیاز دارد؟
منابع
- G. K. Chesterton, The Thing، 1929، فصل The Drift from Domesticity.