Refactoring Code – #1

A lot of things have happened since the last time I wrote a post which seems to be around August 2018 here. The post was inspired from a Swift class I was teaching. At the time it was Swift 4.2 and now we have Swift 5.3. During this time, I worked for a few organizations further developing their apps. The organisations are quite large with user base that spans a large number in 6 digits. However since the code was written over a period of time by several developers, there are interesting artifacts that can be found in the code.

Problems with these codebase

There are several issues that these codebases have had, some of them are listed below
1. There is a poor CI/CD pipeline
2. There are far too many files that get compiled everytime there is a change
3. The codebase is written by Java developers in swift or devs that just got started with swift
4. There is no consistency in terms of using enums or structures or classes
5. There are extensions and overridden methods on extensions, like subclassing

How to fix these

While many of these issues can be fixed easily, like setting up a CI/CD pipeline. Others are a bit more complex to solve and require a lot more. So let’s see how to solve some of these.

#2. Too many files that get compiled

This is relatively easier to solve and fix. If the issue is with Pods (some projects have literally more pods than classes in the project) then one way could be to use pre-compiled binaries. This saves time by not compiling them when a project is being compiled/built. Proceed with caution on this one as if you commit the binaries to your repo, it will suddenly grow exponentially and can reach greater than 1 GB in size.
The other way is to separate the files into frameworks, so that only the frameworks that change are compiled

#4. There is no consistency

This one was also easy to fix, introducing a linter fixed a great deal of problems and also highlighted the casualness employed by earlier developers.
There are many interesting facets that are uncovered when using a linter. Some developers create a rule file and disable most of the rules so that the linter would not produce any warnings. The most common ones are the size of functions/code and the size of variable names. These are mostly disabled.

#5. There are extensions and overridden methods

This is perhaps less common amongst the points above. However I have seen a codebase where the developers have tried to use extensions as subclasses.

#3. The codebase is written by Java developers

This is something that cannot be changed. The code smells shall remain depending on the developers that work on the project, each has their own style. There are some that while writing swift native code end up adding portions of React, Redux, write loops and statements like Java code, mainly because there is a new move towards full stack developers and a lot of devs that come from developing backend systems generally write them in C# (DotNet) or Java (Spring Boot) and thereby the code smell.


Given all of these issues, the way to fix some of them is to rewrite the code and that’s where the actual problem comes in. Generally a majority of developers look for code that does what they want, and that quick fix is all that they want. Sites that offer these little bytes of code are popular, after all it provides something that they are looking for. Because majority of the code written is Copy Paste code it can have blocks that work but overall the code does not flow. It does not read well, it is more like a collection of different chairs at the same dinner table.

Show me the code

If you are also here for the code and not the commentary around it then lets get down to the first part of this.

let’s consider the code where we have a class/structure and then to add sample data to this class/structure

struct Dessert {
  let name: String 
  let calories: Int

and then somewhere in the code we can create some sample desserts like

let sampleDesserts = [
    Dessert(name: "Lemon Tart", calories: 300),
    Dessert(name: "Sponge Cake", calories: 400),
    Dessert(name: "Jelly", calories: 50)

However this is the older way and the most common way, I personally prefer the Swifty way which is to add the same to the struct as static variables as

extension Dessert {
    static var lemonTart = Dessert(name: "Lemon Tart", calories: 300)
    static var spongeCake = Dessert(name: "Sponge Cake", calories: 400)
    static var jelly = Dessert(name: "Jelly", calories: 50)

and then we can simply create the array of desserts as

let sampleDesserts: [Dessert] = [ .lemonTart, .spongeCake, .jelly]

This was it is more readable and cleaner and most importantly Swifty code.

In the next article we shall look at some other code and look at how we can re-write it or refactor it to make it better.

Views All Time
Views All Time
Views Today
Views Today
Posted in Article, Code, Tutorial, Uncategorized.