When working with legacy code one is often presented with functions or even classes with little to no organization. Occasionally functions can even be 2,000 or more lines long! When presented with this situation it can seem like there is little hope of ever achieving proper code quality. While there may not be time (since there are features to build and bugs to fix) to do a lengthy refactor there is still a chance to clean the code up. The best way to improve the code in these instances is to take it slowly and make iterative improvements while working on other features. For example when tasked with adding some code to a 2,000 line method for a new feature one would want to add a new function for that feature. When doing that it isn't too much more work to extract a few more functions from the large function that each have a singular responsibility. When the next new feature comes along in that area you can extract a few more, and so on. Eventually the 2,000 line function becomes 20+ smaller functions with singular responsibilities. At this point it will likely be clear that some of these functions belong together in cohesive classes. After grouping the functions into classes the massive 2,000 line method is now broken up into around 5 classes with functions that each have a single responsibility and are easy to follow and extend. The legacy code that was originally nearly impossible to reason about is now a bastion of code quality due to iterative refactoring, and it was all done while still delivering features.