همه برنامه‌نویس‌ها در مواقعی باید کد موجود را بازنویسی کنند. اما قبل از این که بخواهی این کار را بکنی، لطفا به موارد پایین فکر کن چون این‌ها می‌تواند باعث صرفه‌جویی زیادی در زمان تو و دیگران بشود و البته کاهش درد و رنج:

• بهترین روش برای بازسازی با بررسی کدهای موجود و تست‌هایی که برای آن نوشته شده است آغاز می‌شود. این کار به درک نقاط قوت و ضعف کد در وضعیت فعلی کمک می‌کند. با این کار می‌توانی مطمئن شوی که در عین دوری از خطاها، نقاط قوت را حفظ می‌کنی. همه ما گمان می‌کنیم که می‌توانیم کار را بهتر از سیستم فعلی انجام دهیم… تا زمانی که در آخر کار نتیجه نه تنها بهتر نمی‌شود که حتا ممکن است بدتر از سیستم قبلی هم بشود، به خاطر این که از خطاهای سیستم موجود درس نگرفتیم.
• در برابر وسوسه بازنویسی همه چیز مقاومت کن. بهترین کار این است که تا جای ممکن از کدهای موجود استفاده مجدد کنی. اصلا مهم نیست که چقدر کد زشت است، این کد پیش از این تست و بازنگری و … شده است. دور ریختن کد قدیمی -به خصوص اگر در حال استفاده باشد- به این معنی است که کدی که ماه‌ها (یا سال‌ها) تست شده و در مشکلات مقاوم شده است را دور می‌ریزی، کدی که ممکن است شامل برخی راه‌حل‌ها و حل خطاهایی باشد که حتا از وجود آن‌ها مطلع نیستی. اگر این نکته را جدی نگیری ممکن است کد تازه‌ای که نوشته‌ای به همان خطاهای مرموز بخورد که در کد قبلی اصلاح شده‌اند. این مشکل ممکن است زمان زیادی را به هدر بدهد و سختی‌های زیادی را به تو تحمیل کند و به دانشی که در طول سال‌ها به دست آمده است لطمه بزند.
• تعداد زیادی تغییرات تدریجی بهتر از یک تغییر عظیم است. تغییرات تدریجی اجازه می‌دهد که تاثیر بر روی سیستم را از طریق بازخورد و تست بسیار ساده‌تر اندازه بگیری. دیدن صدها تست ناموفق بعد از یک تغییر اصلا مسأله جذابی نیست. این موضوع به ناامیدی منجر می‌شود و فشاری که به تو وارد می‌کند باعث می‌شود تصمیم‌های بد بگیری. سر و کله زدن با چند تا تست ناموفق در هر مرحله بسیار ساده‌تر است و تو را به روشی مدیریت شده بعد از هر چرخه هدایت می‌کند. مهم است که تست‌های فعلی همه با موفقیت انجام بشوند. اگر تست‌های فعلی برای پوشش تغییراتی که در کد داده‌ای کافی نبود تست‌های جدید اضافه کن. تست‌های موجود کد قدیمی را بدون دلیل موجه دور نریز. در یک نگاه سطحی ممکن است برخی از این تست‌ها در طراحی جدید تو کاربردی نداشته باشند اما عمیق شدن در آن‌ها و کشف علت نوشته شدن این تست‌ها ارزشمند است.
• ترجیحات شخصی و احساسات نباید در این کار دخیل باشند. اگر چیزی از کار نیفتاده است، چرا می‌خواهی آن را تعمیر کنی؟ [سری که درد نمی‌کند را دستمال نبند.] این که سبک کد نویسی یا ساختار آن کد مطابق ترجیحات شخصی تو نیست دلیل معتبری برای بازنویسی نیست. این نکته هم که فکر می‌کنی می‌توانی کار را بهتر از برنامه‌نویس قبلی انجام بدهی دلیل موجهی نیست.
• فناوری جدید دلیل کافی برای بازنویسی نیست. یکی از بدترین دلایل برای بازنویسی این است که کد فعلی بسیار عقب‌تر از فناوری‌های با حالی است که این روزها ما در اختیار داریم و معتقدیم که زبان جدید یا چارچوب جدید می‌تواند کارها را بسیار شیک‌تر انجام دهد. تا زمانی که تحلیل هزینه-فایده ثابت نکرده است که زبان یا چارچوب جدید باعث ارتقای عظیم در کارایی، قابلیت نگهداری، بهره‌وری می‌شود، بهتر است به آن‌ها دست نزنی.
• به یاد داشته باش که انسان جایزالخطا است. بازسازی همیشه تضمین نمی‌کند که کد جدید بهتر از -یا حتا به خوبی- تلاش‌های قبلی باشد. من تعداد زیادی بازنویسی‌های ناموفق را دیده‌ام و در برخی از آن‌ها مشارکت داشته‌ام. تجربه قشنگی نبود، ولی انسان است و خطاهایش.

Rajith Attapattu