بازآرایی بیخطر: تمیز کردن کد بدون توقف تحویل
هر تیم فنی، در جایی از عمر یک سامانه، این جمله را میگوید: «این کد را باید از اول نوشت».
معمولاً هم راست میگوید. مسئله این است که جملهٔ بعدی — «سه ماه به ما وقت بدهید» — تقریباً هیچوقت به نتیجه نمیرسد. بازنویسیها دیر میشوند، سامانهٔ قدیمی در همان مدت تغییر میکند، و در ماه چهارم شرکت دو سامانهٔ نیمهکاره دارد به جای یکی.
آنچه جواب میدهد چیز دیگری است: بازآرایی مستمر و کوچک، درون همان کاری که بههرحال انجام میشود.
اول، تفکیکی که همهچیز به آن بستگی دارد
سه کار متفاوت که یک اسم گرفتهاند:
بازآرایی — ساختار کد عوض میشود، رفتارش نه. هیچ قابلیتی اضافه یا کم نمیشود. از بیرون، هیچکس نباید بتواند بفهمد این کار انجام شده.
تغییر رفتار — قابلیت جدید یا اصلاح رفتار.
بازنویسی — دور انداختن و ساختن دوباره.
قاعدهای که بیشترین اثر را دارد: این سه را در یک تغییر قاطی نکنید. بازبینی کدی که همزمان ساختار و رفتار را عوض کرده، عملاً غیرممکن است — و اگر باگی بیرون بیاید، کسی نمیداند از کدامشان آمده. یک تغییر که فقط جابهجا میکند و یک تغییر که فقط رفتار را عوض میکند، دو بازبینی سادهاند.
پیششرطی که قابل معامله نیست
بدون تست، بازآرایی نکنید.
تعریف بازآرایی این است که رفتار عوض نشود. اگر راهی برای اثبات این ندارید، در حال بازآرایی نیستید؛ در حال تغییر کور کد کاری هستید که کار میکرد.
و اینجا مسئلهٔ مرغ و تخممرغ پیش میآید: کد قدیمی معمولاً تست ندارد، و تستنوشتن برایش سخت است چون ساختارش بد است.
راه بیرون آمدن، تست مشخصهای است: تستی که رفتار فعلی را — درست یا غلط — ثبت میکند. ورودی معمول بدهید، خروجی را ذخیره کنید، و تست را طوری بنویسید که هر انحرافی از آن خروجی را اعلام کند.
این تست نمیگوید کد درست است. میگوید کد همان کاری را میکند که دیروز میکرد — و برای بازآرایی دقیقاً همین لازم است. جای این تست در تصویر بزرگتر، در استراتژی تست آمده.
از کجا شروع کنیم
نه از زشتترین فایل. از پرترددترین فایل.
سه سیگنالی که ناحیهٔ درست را نشان میدهند:
فایلهایی که بیشترین تغییر را داشتهاند. تاریخچهٔ مخزن این را رایگان به شما میدهد. کدی که سالی یک بار باز میشود، هرچقدر هم بد باشد، هزینهٔ کمی دارد.
فایلهایی که بیشترین باگ را تولید کردهاند. اگر گزارشهای باگ را برچسب زده باشید، این فهرست از قبل موجود است.
جایی که تخمینها همیشه غلط از آب درمیآیند. اگر هر تغییری در ماژول حسابداری سه برابر برآورد طول میکشد، آن ماژول است که باید تمیز شود — صرفنظر از اینکه کدش چقدر بد به نظر میرسد.
تقاطع این سه، فهرست کوتاهی میدهد. آن فهرست، همان چیزی است که بدهی فنی را از احساس به عدد تبدیل میکند.
روش: قاعدهٔ اردوگاه
سادهترین رویهای که در عمل جواب میدهد: هر فایلی را که برای کاری باز میکنید، کمی تمیزتر از آنچه بود ببندید.
نه یک ساعت. ده دقیقه. یک نام بهتر، یک تابع طولانی که به دو تا شکسته میشود، یک شرط تودرتو که ساده میشود، یک بخش تکراری که یکی میشود.
سه چیز این کار را ممکن میکند:
تغییرها کوچک بمانند. بازآراییای که در یک بازبینی جا نشود، بازآراییای است که یا سرسری بازبینی میشود یا هفتهها معلق میماند و با کار بقیه تداخل پیدا میکند.
در همان شاخهٔ کار اصلی ادغام شود. شاخهٔ بازآرایی که سه هفته باز بماند، به یک ادغام دردناک تبدیل میشود.
تیم اجازهاش را داشته باشد. اگر هر ده دقیقه تمیزکاری باید در جلسه توجیه شود، انجام نمیشود. این تصمیم مدیریتی است، نه فنی.
وقتی تغییر بزرگ لازم است
گاهی واقعاً یک تغییر ساختاری بزرگ لازم است: جدا کردن یک ماژول، عوض کردن مدل داده، کنار گذاشتن یک وابستگی قدیمی. اینجا هم «بازنویسی» جواب نیست؛ گذار موازی جواب است.
الگوی کلی: ساختار جدید کنار قدیمی ساخته میشود، ترافیک تدریجاً منتقل میشود، و قدیمی وقتی هیچچیز به آن وابسته نیست حذف میشود. برای سامانههای بزرگ، شکل کامل این کار الگوی خفهکننده است و برای سطح ماژول هم همان منطق برقرار است.
سه ابزاری که گذار موازی را ممکن میکنند:
پرچم قابلیت — تا بشود بدون انتشار جدید بین قدیم و جدید سوئیچ کرد. جزئیاتش در راهبرد استقرار.
اجرای موازی — هر دو مسیر اجرا میشوند، فقط نتیجهٔ قدیمی استفاده میشود، و اختلافها لاگ میشوند. برای منطق محاسباتی — قیمت، مالیات، کارمزد — این مطمئنترین روشی است که میشناسیم.
تاریخ حذف مکتوب. کد قدیمی که «فعلاً» میماند، پنج سال میماند. تاریخ و شرط حذفش را همانجا که تصمیم ثبت میشود بنویسید.
چه چیزی بازآرایی نیست
تغییر سبک ناگهانی روی کل مخزن. قالببندی مجدد هزار فایل، تاریخچه را بیفایده میکند و هیچ باگی را نمیگیرد. اگر لازم است، در یک تغییر جدا و یکباره، با ابزار خودکار.
عوض کردن فناوری به بهانهٔ تمیزکاری. مهاجرت به فریمورک جدید، بازآرایی نیست؛ پروژه است و باید مثل پروژه توجیه شود.
تمیز کردن کدی که قرار است حذف شود. پیش از هر بازآرایی یک سؤال: این کد سال دیگر هست؟
چطور برای کسی که کد نمیخواند توجیهش کنیم
بحث «کیفیت کد» با مدیر غیرفنی به جایی نمیرسد. آنچه به جایی میرسد، سه عدد است:
زمان تحویل تغییرهای مشابه. اگر تغییری که پارسال دو روز بود امسال شش روز است، بدهی دارد گران میشود.
نسبت کار دوباره. چند درصد کارها به دلیل خرابی ناخواسته برگشتهاند؟
تمرکز باگها. «شصت درصد باگهای سه ماه اخیر از دو ماژول آمدهاند» جملهای است که تصمیم میسازد.
اینها اعدادی هستند که کسی که بودجه را امضا میکند میفهمد، و بدهی فنی را از سلیقهٔ مهندسی به هزینهٔ مالکیت تبدیل میکنند.