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

پیش از آن که اقدام به بازنویسی کدهای خود کنید، حتماً موارد زیر را مد نظر قرار دهید: همواره یکی از بهترین رویکردها نسبت به این که کدهای خود را بازنویسی کنیم یا نکنیم این است که کدها را با استفاده از تست هایی که برای آن‌ها می نویسیم تست کنیم چرا که با این کار به نقاط ضعف و قوت برنامه خود به خوبی پی برده و زمانی که بخواهیم کدها را Refactor کنیم، بخش‌هایی از کد که دارند به خوبی کار می‌کنند را دست کاری نخواهیم کرد اما در عین حال نقاط ضعف را برطرف خواهیم نمود. برنامه نویس ها همواره فکر می‌کنند که می‌توانند کدی بنویسند که بهتر از کد فعلی کار کند و این همان اشتباهی است که می بایست تا حد ممکن از آن اجتناب کرد.

هشدار

علاوه بر این، حتماً بایستی مقابل وسوسه بازنویسی هر سورس کدی ایستادگی کرد. همواره به خاطر داشته باشیم که بایستی تا حد ممکن از کدهای قبلی استفاده کنیم حتی اگر کدها تمیز نوشته نشده اند! زمانی که کدهای قبلی را پاک می کنیم، این بدان معنا است که ما ماه ها و یا سال‌ها تلاش و کدنویسی را هدر می دهیم.

در فرایند بازنویسی کد، اعمال چندین تغییر ساختاری کوچک به مراتب بهتر است از یک تغییر عمده است. به عبارت دیگر، تغییرات کوچک این امکان را به شما می‌دهند تا تأثیر آن تغییرات را روی برنامه خود راحت‌تر تست کرده و بازخورد آن‌ها را مشاهده نمایید.

پس از تکمیل هر ماژول -یا بهتر بگوییم هر بخش از برنامه- سورس کد ما حتماً بایستی از سد چندین تست عبور کند. به محض این که یک تغییر جدید در کد خود ایجاد می کنید، حتماً تست آن تغییرات را هم بنویسید. در‌ واقع این تست ها عملکردی همچون End User دارند که گویی دارد با برنامه ما کار می‌کند و این اطمینان را حاصل می‌کنند نرم افزاری که به دست مشتری خواهد رسید بدون باگ است. در ضمن، هرگز تست های نرم افزاری قدیمی را پاک نکنید چرا که ممکن است در ماه های گذشته ایده خاصی مد نظر شما بوده که برای تست کردن آن یک Unit Test نوشته‌اید اما اکنون که دارید به بازنویسی کدها می پردازید، فکر شما اصلاً به سمت و سوی آن ایده خاص نرفته است.

سعی کنید تا حد ممکن سلایق شخصی را وارد کدنویسی نکنید. اگر بخشی از کد دارد به درستی کار می کند، اصلاً نیازی به بازنویسی آن نیست. اگر کدهایی که نوشته‌اید تمیز نیستند، این اصلاً دلیل خوبی برای بازنویسی آن‌ها نیست. اگر هم کدهای پیش روی شما از برنامه نویس دیگری به شما به ارث رسیده، احتمال این که فکر کنید کدهای شما به مراتب بهتر از برنامه نویسی قبلی خواهد بود زیاد است که این هم اصلاً دلیل موجهی نیست!

استفاده از فناوری های جدید هم اصلاً دلیل مناسبی برای Refactoring نیست. یکی از بدترین دلایلی که یک برنامه نویسی برای بازنویسی کدها می‌تواند بیاورد این است که کدهای برنامه مربوط به فناوری های چندین سال پیش هستند و در حال حاضر نسخه نرم‌افزارها و زبان‌های برنامه نویسی استفاده شده در آن برنامه به‌ خصوص خیلی ارتقاء یافته اند. در چنین مواقعی حتماً می بایست به بررسی دقیق فریم ورک یا زبان برنامه نویسی مد نظر پرداخته تا ببینیم که آیا نسخه های جدید آن واقعاً بهبود یافته‌اند یا خیر. اگر واقعاً کمکی به بهبود عملکرد، نگهداری و راندمان نرم‌افزار می‌کردند که بایستی به بازنویسی کدها پرداخت و در غیر این صورت می بایست کدها را همان‌طور که هستند رها کرد. در پایان هم همواره به خاطر داشته باشید که آدم‌ها همیشه در معرض ارتکاب خطا هستند. بازنویسی کدها اصلاً بدان معنا نیست که کدهای جدید بهتر از کدهای قبلی یا به همان خوبی کدهای قبلی خواهند بود.

آشنایی با مفهوم ریفکتورینگ در کدنویسی