There are a lot of really great articles out there on many of the advanced and amazing features that Swift has to offer. The articles in this series won’t be like those. Instead, each Monday for the next nine weeks, we’re going to explore new “use every day” tips and methodologies to help keep your codebase maintainable, understandable, and extensible.
Many of the topics that we’ll cover along the way share a common motivation: We are striving to be “small at scope.” I mean this in the normal code-sense but also within the context of a developer’s mind.
Whether we’re organizing the project, cleaning up the namespace, or refactoring code out of the current file, we’re attempting to lower the time and energy a developer needs to solve a problem at any given moment.
There is a balance to be maintained here. Make things too small and the bigger picture can become maddeningly difficult to understand. Allow things to grow too large and it becomes more difficult to track down what you’re actually interested in. Here are some questions that you can ask yourself to help identify areas for improvement:
- Can this data-related code be encapsulated into a data source?
- Can this network-related code be encapsulated into a shared network stack?
- Can this boilerplate code be refactored into a shared subclass or a protocol (with default implementation)?
- Can this helper method be made generic and put in a more accessible place (e.g., higher-order function, type extension, or protocol)?
- Can this enum-related logic be moved into the enum itself as a helper method using Swift’s new rich-enum functionality?
- Can these constants be grouped together into a struct or case-less enum?
Sometimes it’s OK for things to have a large presence, but you should always be questioning if that is necessary.
Check back here and on Twitter every Monday throughout this nine-part series to learn new tips and methods for pragmatic Swift programming.