What should you do first when changing legacy code?

Adding a test first when changing legacy code is a crucial step in ensuring that the existing functionality remains intact throughout the change process. By introducing a test before making any modifications, you create a safety net that allows you to verify that your changes do not introduce new bugs or break existing features. This practice aligns with principles of test-driven development (TDD), emphasizing the importance of having tests to validate the code's behavior.

Focusing on ensuring that the current code is covered by tests before you make changes also helps to build confidence in the modifications. Once the tests are in place, subsequent code changes can be made with the reassurance that you can quickly identify any unintended consequences through these tests.

Rewriting code outright or delegating the task carries its own risks. Rewriting can lead to overhauls that may not address existing issues effectively and could introduce new problems. Delegating might result in loss of context or knowledge about the codebase, potentially leading to further complications down the line. Changing the code first without a test omits the critical step of verification, leaving the code vulnerable to introducing errors without a clear method of detection. Hence, starting with test creation is the most prudent approach when dealing with legacy code changes.