Refactoring

Overview Refactoring is often presented as a straightforward cleanup process, but it is a high-stakes surgery on living logic. This guide explores how even "cleaner" code can introduce regressions by misinterpreting the original intent. We will examine how to transition from messy conditional blocks to a specification pattern using Python lambda functions, while highlighting why code coverage is a deceptive metric for correctness. Prerequisites To follow this guide, you should be comfortable with Python fundamentals, including lambda functions and dictionary mapping. Familiarity with the Pytest framework and the concept of unit testing is essential for understanding how to validate refactored logic against legacy behavior. Key Libraries & Tools * **Pytest**: A robust testing framework used to identify behavioral mismatches between code versions. * **Coverage.py**: A tool for measuring code coverage, though we use it here to demonstrate its limitations in catching logical errors. * **Lambda Functions**: Anonymous functions used to defer the execution of business rules. Code Walkthrough In the original messy implementation, business logic was buried in deeply nested `if-else` blocks. The refactored approach uses a list of "rejection rules" to make the logic declarative. ```python The Refactored Specification rejection_rules = [ lambda order: order.amount > 1000 and not order.user.is_premium, lambda order: order.has_discount and order.type == "bulk", lambda order: not is_valid_currency(order.region, order.currency) ] def approve_order(order): if any(rule(order) for rule in rejection_rules): return "rejected" return "approved" ``` By using `any()` with a list of lambdas, we gain two advantages. First, **lazy execution** ensures we only run rules until the first rejection is found. Second, we separate the **specification** of the rules from the **execution** engine, allowing the rules to be passed as data objects. Syntax Notes: The Data Structure Shift Replacing hardcoded string checks with a dictionary or set significantly improves extensibility. Instead of writing `if region == "EU" and currency != "EUR"`, use a mapping: ```python VALID_PAIRS = {("EU", "EUR"), ("US", "USD")} def is_valid_currency(reg, cur): return (reg, cur) in VALID_PAIRS ``` Tips & Gotchas High test coverage is not a shield against logic errors. You can achieve **86% coverage** while still failing to test edge cases where multiple conditions (like admin status and premium membership) overlap. Always treat the original code as the baseline, but remember that "ground truth" is often a moving target between user needs and technical implementation.