First project in Viper

This blog post is just some personal experience after finishing my first project in Viper. If you haven’t heard of Viper and clean architecture before, you should definetely watch this video:

It’s not like we didn’t use some good practices in our projects before. We already split responsibilities, we did TDD, we used dependency injection a lot. Somehow it all didn’t help much when you open the code several months later or a new person would come to a project. Every separate class was small and understandable and the code was readable and modular, but trying to get the overal architecture of the project was tricky.

Some time ago I learned about Viper (clean architecture for iOS) and was very excited to try it out.

At first it all went well and I was pretty happy about myself while I worked on the project alone. But then another developer joined :) His first reaction was not super encouraging:

Man this viper thing is kinda verbose. I’m writing and stubbing protocols all over the place…

So I looked at the code again. Well, he was right. If you follow the book, you end up with a lot of protocols that would only be used once in most of the cases. Somewhere at that time I also watched this video about keeping your code sustainable:

The main idea I took from it: don’t over engineer, especially if it’s an app, not a framework. If you are not going to have multiple implementations, consider not introducing a protocol. Users of your code base are developers as well! If they ever need to have a protocol there, well, they will add it.

In some cases I would keep the protocols to be able to write unit tests, in others I could throw them away. The code became more clear.

Working on the project felt pretty good. It went smooth, I wasn’t slowed down by the growing codebase. Refactoring was easy, especially when I needed to move some view controllers around. All the navigation logic was nicely isolated.

I was curious if the architecture has indeed became better. It is hard to judge a project you are actively involved in, but I came across a very nice dependency visualiser tool and tried it on some projects.

First one is a project I was working on before. We used a lot of protocols, had unit tests all over the place and our view controllers were not that big, so when I looked at the dependency graph, I was surprised. I actually expected it to be better:

Classes are represented by circles of different colors, the more dependencies you have in your class, the bigger the circle is.

The big blue circle in the centre is AppDelegate. Well, it held refefrences to some top level view controllers, handled some notifications, initialised some data access objects. It seemed like there is not that much code in it, but it still ended up with a lot of nasty dependencies. It makes sense if you think of it. AppDelegate would have a reference to, lets say, RootViewController that in turn would have reference to MenuViewController, etc. And so the dependency roll grows.

The second graph is of my first Viper project. AppDelegate was doing a lot less. Basically it was just creating a root wireframe and passing control to it. Every module knew only about the modules it needed to call directly. This is something you want to have in any project of course, but having all the setup in Wireframes makes the dependencies more exposed and helps to make modules very targeted and isolated.

What I liked the most:

• A lot less bugs. There were almost none of them and the ones that sneaked in were easy to fix.
• Code becomes more like interchangeable lego blocks. Assembling new modules with existing blocks, reassembling old modules, introducing interfaces and adding different implementations for some classes — all was easy to do. Main reason it was this way, I think, is dependency injection and creation/assembly of all of the modules in Wireframes.
• Once again, refactoring was super easy. Imagine that changing the whole navigation tree of the app doesn’t scary you anymore :)

I am very curios to take a look at the project again after some months. But so far it looks very promising!