Aug 26, 2017 · 2 min read
Great article, thanks! In my previous company where I was working as a team lead we had 16+ devs and 8+ testers working pretty much on the same codebase, and code reviews made a hefty part of my / our daily routine, as well as a huge discussion topic. Additional things that help reduce code review times and back and forth conversations are:
- modularizing your architecture by extracting code into sensible private frameworks (we did this by using private CocoaPods), which helps decoupling, testing, but also keeps focus on a smaller piece of software which is then easier to code review.
- defining the architectural patterns and sticking to them. I.e. if the whole app is written with MVVM in mind, stick to that.
- defining and owning the coding style, there are many to pick from, on GitHub so team can pick one upfront and own it.
- planning the implementation before the sprint helped a lot in the early stages of development to reduce the back and forth with code reviews concerning SOLID and OOP practices.
- putting in place a continuous delivery pipeline, with visible monitors of when the build is broken and needs to be fixed. We used Jenkins and fastlane for that.
- automated linting and static analysis with SwiftLint or OCLint or more elaborate tools like Sonar.
- strong collaboration between testers, developers and product owners. We had a very strong coverage with unit tests, but also with functional and integration tests. Also helpful when working on a story, before stuff gets merged, testers can check if the feature has been implemented correctly by checking out the development branch.
