The only way to do Model View Presenter (MVP) and you probably didn’t even know it existed! _Everyone_ on the internet is talking about MVP and everyone likes to share ‘_the best way_’, little do they know the best way is written in this blog. I will talk about how you can architect MVP to work the best for your team. Also when using this specific design how your team can work together to make awesomeness happen quickly and easily. Doing MVP this way also allows for easily testable code and legacy developers to pick up and add features at the drop of a hat.
How do you decide which MVP architecture to use? Here it is. The best way to do MVP is for your team to agree on the approach to and the structure of your architecture.[^1] Then to implement it in a way that the aims and intended behaviour are explicitly documented. The actual way your Model, View and Presenter inter-communicate or the roles that they take is not as important as all **the team agreeing and understanding together how it will work**.
##Why does the team need to agree on MVP architecture
> Each developer will be re-working each others code and in the end you have a big ball of mud.
– [Context switching](https://en.wikipedia.org/wiki/Task_switching_(psychology)#Switch_cost), having multiple ways to implement an architecture means you constantly have to be aware of where you are in the code base. If two objects with the same naming convention (Model, Presenter) have to communicate you would first need to take a step back and see where in the codebase you are. This involves a context switch, and knowing if this is MVP/A or MVP/B before you even start to tackle your original problem, puts more load on your cognitive process and slows you down.
– Too many cooks can spoil your software broth. With multiple architectures and potentially each team member thinking something differently you will never come to a refined, [clean](https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html), simple, [SOLID](https://www.novoda.com/blog/designing-something-solid/) architecture. Each developer would be re-working each others code and in the end you have a [big ball of mud](https://en.wikipedia.org/wiki/Big_ball_of_mud).
– Duplication of ideas. When there are different architectures for expressing the same layer of a codebase it makes it less obvious that you may have behavioural similarities. In this case developers would not be able to see potential refactorings where they could simplify, or for example; remove two View objects in favor of one. [The best code is no code at all](https://blog.codinghorror.com/the-best-code-is-no-code-at-all/).
I could give more reasons ([spaghetti code](https://wiki.c2.com/?SpaghettiCode), [DRY](https://wiki.c2.com/?DontRepeatYourself), [KISS](https://wiki.c2.com/?KeepItSimple), …) but I think you understand. Not being consistent and disagreeing about your architecture is bad. Now how do you get your development team to come to a single understanding of what MVP means for your project?
####How to agree on MVP architecture as a team
> Meetings aren’t your enemy and sometimes it’s the best way to get people singing from the same song sheet.
Agreement starts with talking to each other. It sounds simple but it takes a lot of effort. Explicit communication really helps a team function. Never assume what your other developer team mates are thinking always explicitly state the direction of your thoughts. You’ll be surprised how often someone says “oh I wasn’t thinking of it like that”.
Organise a meeting for everyone to talk about MVP. Meetings aren’t your enemy and sometimes it’s the best way to get people singing from the same song sheet. In meetings always make sure an agenda is set and that there is some explicit outcome from the meeting. Talking things through does not come naturally to developers but it’s a skill all of us can improve.
[Pair programming](https://en.wikipedia.org/wiki/Pair_programming) allows developers to share thoughts and ideas as well as learn from each other. Pairing on an architecture problem like MVP gives a great way for thoughts to be shared by example. You can see what your pair is trying to say in the code in front of you both. You can quickly code up two ideas for an architecture and compare them whilst sitting and talking together.
[Mob programming](https://en.wikipedia.org/wiki/Mob_programming) or _mobbing_ has the same benefits as pair programming except it relates to the whole team. Get everyone in front of the same screen to show the big ideas, agree on the structure and direction of the architecture. It’s a great way for everyone to input and for everyone to get to the same level of understanding of a problem. If you haven’t tried this yet, it’s highly recommended and you will see the benefits by example if you give it a go. Grab your team, a [Kata from here](https://github.com/novoda/dojos) and give it a go.
##Why do you need to document your MVP architecture
> Think of documentation as asynchronous communication, allowing developers to learn from you without you being there.
Documentation is underrated. There has been a massive backlash on documentation in the developer community, everyone has gone for _no documentation_ when actually [literature](https://www.infoq.com/news/2014/01/documentation-agile-how-much) has been trying to explain _minimal documentation_. You can think of documentation as **asynchronous communication**, allowing developers to learn from you without you being there.
Documenting any architectural decisions is really important for the codebase and for the team. You can’t always be there to explain the structural decisions, but the documentation will be there. Having documentation makes the [implicit, explicit](https://www.managementcenter.org/article/how-to-make-the-implicit-explicit/)[^2]. This means less unknowns, leading to less guess work and less mistakes.
You should always consider the [legacy](https://en.wikipedia.org/wiki/Legacy_system) developer as well, don’t be selfish now and think _‘oh this is some person in X years time who cares’_, a legacy developer is also you next week[^3], or your new awesome team mate next month. Having the code and architecture documented frees you up to carry on with your tasks and makes their [onboarding](https://en.wikipedia.org/wiki/Onboarding) a lot smoother and faster.
####How to document your MVP code
> Explain why the code is here and explain things that are not understandable from the code on its own.
Start at the smallest details to encourage a mentality of documentation and explicit communication everywhere. Writing tests allows you to have living documentation. That is your tests can explain expected behaviour of how your architectural elements are supposed to work. You can write tests that show how the view receives data or how the presenter controls aspects of your MVP setup.
Always remember your commit messages can help explain why you are doing something. A great tip for explanatory commit messages is that they should be able to complete this sentence _“If applied, this commit will…”_[^4]. Using commit messages to ensure explicit documentation helps everyone on your team, helps them now when you’re working together and helps them in the future when reviewing already written code.
[Code reviews](https://github.com/blog/2123-more-code-review-tools) are a great example of documentation, when you write up the details of the code you have changed you are explaining to others **why** you have done this, which is quite hard to capture in the code itself. Agreeing through documentation can make the most implicit thoughts of a single developer, explicit for all to read.
Being explicit in your class naming can be the first step to documenting your MVP architecture. Here is a very explicit way of showing other developers exactly how your [MVP framework is structured through class naming](https://www.novoda.com/blog/better-class-naming/). You end up with self documenting code like this:
“`java
public interface TweetsMvp {
interface Model {
…
}
interface View {
…
}
interface Presenter {
…
}
}
“`
You want a naming solution that works for your problem and is agreed by your team, “[Naming is hard](https://martinfowler.com/bliki/TwoHardThings.html)”, but there is also another saying _”you have to be in it to win it”_. If you don’t think about naming as a documenting tool and try to improve your attempts, then naming will always be hard.
Splitting your code into modules allows you to make some implicit boundaries explicit. In Java, modules allow you set in place some rules for what code can go where. For example imagine, a module _A_ with a dependency on library _X_. This means that module _B_ cannot easily write any code that relies on library _X_. Unless you add that dependency to _B_ or more likely you should move whatever you are attempted to module _A_. You can also add a [README](https://github.com/matiassingers/awesome-readme) file to each module to further explain why this separation has occurred.
[Javadoc](https://en.wikipedia.org/wiki/Javadoc) allows you to write code comments in a standardised format explaining why some code or a class exists. If you have an architecture with [boundaries](https://martinfowler.com/bliki/BoundedContext.html) then each part of the code will have a _public_ API, potentially with multiple team members working on each. It’s important to add comments to these public APIs. Just remember you are trying to explain why the code is here and explain things that are not understandable from the code on its own. Another clue for when to write a comment is when you are using a class from one module in another, this is a boundary that should be explained.
Architecture diagrams can be a great team tool, they help understanding of the bigger picture and get consensus on change. The team should agree on a common diagramming syntax and be involved in the creation of architecture diagrams. When you use diagrams it is important that they always resemble the latest thinking in your code base and are kept up to date alongside your project. This is where a tool like the [c4 architecture model](https://www.structurizr.com/help/c4) is beneficial to use, it allows diagrams to be coded and compiled, therefore they form part of your app that you need to keep up to date. Onboarding new team members to a project and even refreshing yourself before a new feature needs to be implemented are great reasons to have and maintain your projects architecture as diagrams.
##Conclusion
There is no single _right_ way to implement Model View Presenter and the one you choose does not matter. What matters is that your team should all agree on **your team’s way** of implementing this UI architecture. Doing so through explicit code, great team communication, always learning and sharing with each other and documenting for the future. This ensures you will have an easy to understand, agreed and hopefully straight forward code base that your team and any future teammates would be happy to start contributing to.
Thanks to [@riggaroo](https://twitter.com/riggaroo), [@FMuntenescu](https://twitter.com/FMuntenescu), [@lgvalle](https://twitter.com/lgvalle) for reviewing the content and my sanity.
——
[^1]: By architecture here, and throughout the article I mean MVP as an **UI architecture**. You still need to architect the rest of your app!
[^2]: Don’t worry about the management speak, this skill applies to everyone and being explicit is important for all communication between everyone.
[^3]: Ever come back to your computer Monday morning, looked at the code you wrote Friday afternoon and thought … what the hell was i thinking? That.
[^4]: So many awesome tips for writing great commit messages [here](https://chris.beams.io/posts/git-commit/), I can’t explain how many “WTF is this code” moments would be resolved if all commit messages were written this way. (fyi usually the code in question is my own written the previous week..)