چک‌لیست بازنویسی کد

بسیاری از برنامه‌نویسان تصور می‌کنند همین که کدشان کار می‌کند و خروجی درست را تحویل می‌دهد، مأموریت آن‌ها به پایان رسیده است. اما واقعیت تلخ در دنیای مهندسی نرم‌افزار این است: کدی که فقط «کار می‌کند»، می‌تواند به مرور زمان به یک کابوس تبدیل شود.

خطوط کدی که امروز با عجله نوشته می‌شوند تا یک ویژگی جدید سریع‌تر به پروژه اضافه شود، فردا مثل سیم‌های درهم‌پیچیده یک جعبه برق، توسعه پروژه را کاملاً قفل می‌کنند. اینجاست که هنر بازنویسی یا ریفکتورینگ (Refactoring) اهمیت خود را نشان می‌دهد؛ فرآیند تغییر دادن ساختار داخلی کد بدون اینکه رفتار بیرونی آن کوچک‌ترین تغییری کند.

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

با مطالعه این درس یاد می‌گیرید که چطور نشانه‌های کدهای بد (Code Smells) را در پروژه‌های خود شکار کنید و با اعتمادبه‌نفس کامل، دست به جراحی و نوسازی کدهای خود بزنید؛ به طوری که بعد از پایان کار، خودتان و هم‌تیمی‌هایتان از خواندن کدهای جدید لذت ببرید.

بازنویسی کد (Refactoring) چیست و چه زمانی باید به سراغ آن برویم؟

بازنویسی کد یا همان ریفکتورینگ به فرآیند اصلاح و بهبود ساختار داخلی یک کد بدون تغییر دادن رفتار بیرونی آن گفته می‌شود. وقتی کدی را ریفکتور می‌کنید، هیچ ویژگی (Feature) جدیدی به نرم‌افزار اضافه نمی‌شود و هیچ باگی هم برطرف نمی‌گردد؛ بلکه کدهای موجود خواناتر، تمیزتر و برای تغییرات آینده انعطاف‌پذیرتر می‌شوند.

این کار دقیقاً مانند مرتب کردن و نوسازی لوله‌کشی‌های داخلی یک ساختمان است؛ ظاهر خانه تغییر نمی‌کند، اما جریان آب بسیار بهینه‌تر و تعمیرات بعدی هزاران بار آسان‌تر می‌شود.

توسعه‌دهندگان حرفه‌ای بازنویسی کد را یک بخش جدایی‌ناپذیر از چرخه روزانه کار خود می‌دانند. این فرآیند از انباشته شدن بدهی فنی (Technical Debt) جلوگیری می‌کند و مانع از سنگین و غیرقابل کنترل شدن پروژه در درازمدت می‌شود.

چه زمانی باید به سراغ ریفکتورینگ برویم؟

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

قانون سه بار تکرار (Rule of Three): وقتی برای اولین بار کاری را انجام می‌دهید، کد را بنویسید. بار دوم که با مسئله مشابهی برخورد کردید، شاید کپی کردن کد کارتان را راه بیندازد. اما بار سوم که مجبور شدید همان منطق را تکرار کنید، بلافاصله دست از کار بکشید؛ این دقیقاً زمان ریفکتور کردن و تبدیل آن به یک تابع یا کلاس چندبارمصرف است.

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

در زمان بررسی کدها (Code Review): فرآیند بازبینی کد در تیم، یکی از بهترین فرصت‌ها برای شناسایی نقاط کور پروژه است. اگر هنگام توضیح دادن کد خود به هم‌تیمی‌تان مجبورید زمان زیادی را صرف توجیه پیچیدگی‌های یک تابع کنید، این یک زنگ خطر جدی است. آن تابع باید فوراً ساده‌سازی و بازنویسی شود.

چه زمانی نباید کدها را بازنویسی کنیم؟

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

بوی بد کد (Code Smells)؛ نشانه‌های پنهانی که فریاد می‌زنند کد را بازنویسی کنید

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

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

توابع و کلاس‌های غول‌پیکر (Long Method & Large Class)

توابعی که طول آن‌ها از یک صفحه مانیتور فراتر می‌رود، اولین و واضح‌ترین نشانه کدهای کثیف هستند. یک تابع پایتونیک باید فقط و فقط یک کار مشخص را انجام دهد (اصل تک‌مسئولیتی یا SRP). وقتی یک تابع هم‌زمان داده را از دیتابیس می‌گیرد، آن را پردازش می‌کند، ایمیل می‌فرستد و خروجی را لاگ می‌کند، یعنی با یک تابع غول‌پیکر مواجه هستید. کلاس‌های بزرگ نیز که صدها خط کد و ده‌ها متد مختلف را در خود جای داده‌اند، نگهداری پروژه را غیرممکن می‌کنند.

لیست آرگومان‌های طولانی (Long Parameter List)

ورودی‌های یک تابع نباید شبیه به لیست خرید یک فروشگاه بزرگ باشد. اگر برای صدا زدن یک تابع مجبورید بیش از ۳ یا ۴ آرگومان به آن پاس دهید، کد شما دچار این بوی بد شده است. طولانی بودن لیست آرگومان‌ها، خوانایی کد را به شدت کاهش می‌دهد و نوشتن تست‌های خودکار را سخت می‌کند. در این حالت، معمولاً پاس دادن یک شیء (Object) یا یک دیکشنری به عنوان ورودی، راهکار بسیار بهتری است.

کدهای تکراری (Duplicated Code)

کپی-پیست کردن کدهایی که ساختار مشابهی دارند، بزرگ‌ترین گناه در مهندسی نرم‌افزار است. این کار اصل مهم DRY (دوباره کاری نکن) را نقض می‌کند. خطر کدهای تکراری زمانی مشخص می‌شود که بخواهید یک منطق یا باگ را اصلاح کنید؛ در این صورت باید ده جای مختلف از پروژه را دستکاری کنید و کافی است یک جا را از قلم بیندازید تا کل سیستم به هم بریزد.

دلبستگی به ویژگی‌ها (Feature Envy)

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

قدم صفر ریفکتورینگ؛ چرا بدون تست‌های خودکار نباید دست به کد بزنید؟

دست بردن در کدی که در حال حاضر بدون مشکل در سرورهای زنده اجرا می‌شود، مانند راه رفتن روی میدان مین است. فرقی نمی‌کند چقدر برنامه‌نویس باذکاوت یا با‌تجربه‌ای باشید؛ وقتی ساختار داخلی یک کد پیچیده را تغییر می‌دهید، احتمال اینکه بخش دیگری از نرم‌افزار را به طور ناخواسته از کار بیندازید، بسیار زیاد است. به همین دلیل، برنامه‌نویسان حرفه‌ای هرگز بدون داشتن یک شبکه امنیتی محکم، فرآیند بازنویسی کد را آغاز نمی‌کنند. این شبکه امنیتی چیزی نیست جز تست‌های خودکار (Automated Tests).

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

قانون طلایی: ابتدا تست بنویسید، سپس ریفکتور کنید

اگر کدی که قصد بازنویسی آن را دارید فاقد تست‌های واحد (Unit Tests) یا تست‌های یکپارچه‌سازی (Integration Tests) است، ورود به فرآیند ریفکتورینگ یک خودکشی فنی به شمار می‌رود. قدم صفر این است که ابتدا برای وضعیت فعلی کد، تست‌های جامع بنویسید. این تست‌ها باید تمام حالت‌های ممکن، ورودی‌های عادی و رفتارهای مرزی (Edge Cases) تابع یا کلاس مورد نظر را پوشش دهند.

وقتی تست‌ها را اجرا کردید و از سبز بودن (پاس شدن) آن‌ها مطمئن شدید، تازه چراغ سبز برای شروع بازنویسی روشن می‌شود. حالا می‌توانید با خیال راحت و با اتکا به متدولوژی‌های بهینه‌سازی، ساختار کد را تغییر دهید. بعد از هر تغییر کوچک، تست‌ها را مجدداً اجرا کنید. اگر چراغ تست‌ها همچنان سبز ماند، یعنی مسیر را درست رفته‌اید؛ اما اگر حتی یکی از تست‌ها قرمز شد، یعنی ناخواسته منطق برنامه را تغییر داده‌اید و باید فوراً کد را اصلاح کنید.

چگونه تست‌های خودکار مانع از ترس توسعه‌دهنده می‌شوند؟

بزرگ‌ترین مانع در برابر تمیز کردن کدهای یک پروژه بزرگ، «ترس» است. ترس از اینکه دست زدن به این تابع قدیمی، باعث خرابی بخش پرداخت یا ثبت‌نام سایت شود. وجود تست‌های خودکار این ترس را کاملاً ریشه‌کن می‌کند.

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

بخش اول چک‌لیست: جراحی توابع طولانی و شکستن منطق‌های پیچیده

توابع طولانی که اصطلاحاً به آن‌ها توابع خدا (God Methods) هم می‌گویند، به این دلیل به وجود می‌آیند که برنامه‌نویس تمایل دارد تمام مراحل یک کار را پشت سر هم در یک جا بنویسد. این کار خوانایی را از بین می‌برد و تست کردن کد را غیرممکن می‌کند. بر اساس چک‌لیست بازنویسی، اولین قدم در جراحی این توابع، بکارگیری تکنیک استخراج متد (Extract Method) است.

اگر برای درک بخش‌های مختلف یک تابع مجبور شده‌اید از کامنت‌ها استفاده کنید، آن بخش‌ها مستعد تبدیل شدن به یک تابع مستقل هستند. با شکستن منطق‌های پیچیده به توابع کوچک‌تر، کد شما خودسند (Self-Documenting) می‌شود؛ یعنی نام توابع جدید کارکرد آن‌ها را توضیح می‌دهد و نیازی به کامنت‌های اضافه نخواهد بود.

گام‌های عملیاتی جراحی توابع

برای شکستن یک منطق پیچیده، ساختار زیر را در کدهای خود پیاده‌سازی کنید:

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

یک مثال واقعی و ملموس در پایتون

به این تابع طولانی و شلوغ که وظیفه ثبت سفارش و ارسال فاکتور را بر عهده دارد نگاه کنید:

# کد کثیف و طولانی قبل از بازنویسی
def process_order(order_id, user_id, items):
    # ۱. محاسبه قیمت کل
    total = 0
    for item in items:
        total += item["price"] * item["quantity"]

    # ۲. اعمال تخفیف
    if total > 1000000:
        total *= 0.9

    # ۳. ذخیره در دیتابیس
    db.save_order(order_id, user_id, total)

    # ۴. ارسال ایمیل فاکتور
    print(f"Sending email to user {user_id} with total {total}")

حالا به کمک چک‌لیست ریفکتورینگ، این تابع غول‌پیکر را به توابع کوچک، تک‌مسئولیتی و پایتونیک زیر جراحی کنید:

# کد تمیز و بازنویسی شده
def calculate_total_price(items):
    total = sum(item["price"] * item["quantity"] for item in items)
    if total > 1000000:
        total *= 0.9
    return total


def send_invoice_email(user_id, total):
    print(f"Sending email to user {user_id} with total {total}")


def process_order(order_id, user_id, items):
    total_price = calculate_total_price(items)
    db.save_order(order_id, user_id, total_price)
    send_invoice_email(user_id, total_price)

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

بخش دوم چک‌لیست: پاک‌سازی شرط‌های تو در تو (Arrow Anti-Pattern) با گارد کلوزها

یکی از آزاردهنده‌ترین اتفاقات در کدهای قدیمی، مواجه شدن با شرط‌های متوالی و تو در تو است. وقتی چند دستور if درون یکدیگر قرار می‌گیرند، کد به مرور زمان به سمت راست مانیتور متمایل می‌شود و ساختاری شبیه به نوک پیکان پیدا می‌کند. در مهندسی نرم‌افزار به این وضعیت آنتی‌پترن پیکان (Arrow Anti-Pattern) یا هرم مرگ می‌گویند. خواندن این کدها ذهن برنامه‌نویس را به شدت خسته می‌کند، چون مجبور است هم‌زمان چندین لایه شرطی را در حافظه کوتاه‌مدت خود نگه دارد.

راهکار کلیدی چک‌لیست ما برای حل این مسئله، استفاده از گارد کلوزها (Guard Clauses) است. گارد کلوز یعنی بررسی حالت‌های خاص، خطاها و ورودی‌های نامعتبر در همان ابتدای تابع و خارج شدن فوری از برنامه با استفاده از دستور return یا raise. با این تکنیک، مسیر اصلی کد (Happy Path) کاملاً صاف و بدون تورفتگی‌های اضافه باقی می‌ماند.

یک مثال واقعی و ملموس در پایتون

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

# کد کثیف با ساختار پیکانی و شرط‌های تو در تو
def check_loan_eligibility(user):
    if user.is_active:
        if user.credit_score > 700:
            if user.has_steady_income:
                return "وام تایید شد"
            else:
                return "خطا: درآمد پایدار یافت نشد"
        else:
            return "خطا: امتیاز اعتباری پایین است"
    else:
        return "خطا: حساب کاربری فعال نیست"

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

# کد تمیز و خوانا با استفاده از گارد کلوزها
def check_loan_eligibility(user):
    if not user.is_active:
        return "خطا: حساب کاربری فعال نیست"

    if user.credit_score <= 700:
        return "خطا: امتیاز اعتباری پایین است"

    if not user.has_steady_income:
        return "خطا: درآمد پایدار یافت نشد"

    # مسیر اصلی و بدون دردسر برنامه
    return "وام تایید شد"

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

بخش سوم چک‌لیست: بهبود نام‌گذاری‌ها و حذف کامنت‌های اضافه

کدهای تمیز کدهایی هستند که بدون نیاز به هیچ راهنمایی، داستان خود را برای خواننده روایت می‌کنند. انتخاب نام‌های مبهم برای متغیرها و توابع، برنامه‌نویسان دیگر را مجبور می‌کند تا برای فهمیدن کد زمان زیادی تلف کنند یا به کامنت‌های متنی پناه ببرند. بر اساس چک‌لیست بازنویسی، کامنت‌ها نباید برای توضیح دادن «کدهای بد و نامفهوم» استفاده شوند؛ بلکه خود کد باید آن‌قدر واضح باشد که نیازی به توضیح اضافه باقی نماند.

رعایت اصول نام‌گذاری پایتونیک، کدهای شما را خودسند (Self-Documenting) می‌کند. در این لایه از چک‌لیست، هدف ما جایگزین کردن نام‌های بی‌معنی با عبارات معنادار و حذف کامنت‌های تکراری یا منسوخ شده است.

اصول انتخاب نام‌های معنادار و حرفه‌ای

هنگام بررسی و اصلاح نام‌ها در پروژه، ساختار زیر را اعمال کنید:

• انتخاب نام بر اساس هدف، نه نوع داده: به جای استفاده از اسامی کلیشه‌ای مانند data_list یا user_obj، نامی انتخاب کنید که نشان دهد این متغیر چه چیزی را درون خود نگه می‌دارد؛ مانند active_subscribers.
• استفاده از افعال برای توابع: توابع عملیاتی را انجام می‌دهند، بنابراین نام آن‌ها باید با یک فعل شروع شود؛ مانند send_notification یا calculate_tax.
• دوری از مخفف‌های من‌درآوردی: از نام‌گذاری متغیرها با حروف مبهم مثل d یا info_x به شدت خودداری کنید. نام متغیر باید دقیقاً مشخص باشد؛ مانند days_since_last_login.

پاک‌سازی کامنت‌های اضافه و بوی بد آن‌ها

یکی از اشتباهات رایج، نوشتن کامنت برای واضحات است. کامنتی که می‌گوید x = 5  # مقدار ایکس را ۵ قرار بده هیچ ارزشی ایجاد نمی‌کند و فقط حجم فایل را بالا می‌برد. کامنت‌ها باید چرایی (Why) یک تصمیم پیچیده مهندسی را توضیح دهند، نه اینکه چه چیزی (What) در کد در حال رخ دادن است. اگر حس می‌کنید یک خط کد بدون کامنت فهمیده نمی‌شود، ابتدا نام متغیرها یا توابع آن خط را ریفکتور کنید، سپس کامنت را پاک کنید.

یک مثال واقعی و ملموس در پایتون

به این قطعه کد که پر از نام‌های مبهم و کامنت‌های توضیحی اضافه است نگاه کنید:

# کد کثیف با نام‌گذاری ضعیف و کامنت‌های مزاحم

# بررسی مجاز بودن کاربر
def chk(u):
    # اگر زمان ثبت‌نام بیشتر از ۳۰ روز باشد و وضعیت فعال باشد
    if u.d > 30 and u.st == "active":
        return True
    return False

حالا به کمک چک‌لیست، نام‌ها را اصلاح کرده و کامنت‌های اضافه را حذف کنید. ببینید کد چطور خودش کارکردش را فریاد می‌زند:

# کد تمیز، خودسند و بدون کامنت‌های اضافه


def is_eligible_for_discount(user):
    has_thirty_days_membership = user.days_since_registration > 30
    is_account_active = user.status == "active"

    return has_thirty_days_membership and is_account_active

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

بخش چهارم چک‌لیست: سنجش کارایی و اطمینان از عدم تغییر رفتار برنامه

آخرین مرحله در چک‌لیست بازنویسی، ارزیابی خروجی کار و اطمینان از سلامت کامل پروژه است. ریفکتورینگ زمانی موفقیت‌آمیز است که ساختار کد زیباتر شده باشد، بدون اینکه سرعت اجرای برنامه کاهش یابد یا رفتار آن دستخوش تغییر شود. در این گام، شما باید کدهای جدید را زیر ذره‌بین قرار دهید تا مطمئن شوید هیچ گلوگاه کارایی جدیدی (Performance Bottleneck) به سیستم اضافه نشده است.

برای نهایی کردن فرآیند بازنویسی و تحویل یک کد ضدگلوله، دو مرحله سنجش نهایی را در پروژه خود اجرا کنید.

گام اول: اجرای مجدد و تست هم‌پوشانی (Regression Testing)

اولین کاری که پس از پایان تغییرات ساختاری باید انجام دهید، اجرای کل پکیج تست‌های خودکار پروژه است. تمام تست‌های واحد و یکپارچه‌سازی که در قدم صفر آماده کرده بودید، باید یک‌بار دیگر اجرا شوند.

اگر تمام تست‌ها همچنان وضعیت سبز (Passed) را نشان دهند، یعنی شما به هدف اصلی ریفکتورینگ رسیده‌اید و رفتار بیرونی نرم‌افزار دقیقاً مانند گذشته است. اما اگر کوچک‌ترین خطایی رخ دهد، نشان می‌دهد که در زمان ساده‌سازی شرط‌ها یا شکستن توابع، بخشی از منطق اصلی برنامه را ناخواسته تغییر داده‌اید.

گام دوم: سنجش کارایی و بهینه‌بودن مصرف حافظه

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

• بررسی بازدهی زمانی (Execution Time): اگر بخش بازنویسی‌شده شامل حلقه‌های پیچیده یا کوئری‌های دیتابیس است، زمان اجرای آن را با ابزارهایی مثل ماژول timeit در پایتون اندازه بگیرید. کد جدید نباید کندتر از کد قبلی اجرا شود.
• بهینه‌سازی کوئری‌ها در جنگو: اگر در فریم‌ورک جنگو کار می‌کنید، مطمئن شوید که با شکستن توابع، تعداد درخواست‌ها به دیتابیس افزایش نیافته باشد. بروز خطای معروف $N+1$ مشکلی است که گاهی در زمان ریفکتورینگ نامناسب مدل‌ها رخ می‌دهد. استفاده از ابزارهایی مانند Django Debug Toolbar برای بررسی تعداد دقیق کوئری‌ها در این گام ضروری است.

پس از عبور موفقیت‌آمیز از این دو گام، کد شما آماده ادغام (Merge) با شاخه اصلی پروژه است. اکنون شما کدی در دست دارید که نه تنها کار می‌کند، بلکه خوانا، سریع، منعطف و مایه افتخار تیم توسعه شماست.