Refactoring feels like a step back.
Last Sunday, I hung out with some
Indie Developers you might know, and I had a chat with
Hidde about some of the code he showed me. Hidde asked me about a centralized file in his project that contained much of his logic.
We quickly started discussing refactoring and the fact that a refactor can often feel like a step back. You could have used that valuable time to develop new features instead, isn't it?
In the same discussion, we mentioned tests. I'm pretty sure you'll have fewer large files if you write tests often simply because it's harder to write tests for large files. There's no overview, and it's hard to find out what you need to test.
While it's hard to measure the gains of a refactor, I'm pretty sure there are many cases in which you'll benefit from readable and testable code. Especially in SwiftUI, having one large file that is also used as an ObservableObject can easily lead to unexpected behavior and unneeded redraws of your views: simply because many views will depend on the many responsibilities of the main file.
If you're asking yourself the question now about how to find out whether you need a refactor, I will encourage you to look at your code and find out whether you've been using many // MARK statements or filenames like "DataController+Content" or "DataController+Images." Both indicate where you could introduce single responsibility, like "ContentStore" and "ImageFetcher."
Refactoring can be a great way to gain new insights. Increase productivity, and simplify testing. Yes, it costs time, but will it cost more than it saves you? Who knows!
Enjoy this week's SwiftLee Weekly!
