Follow one dev as he uses Pomodoros to build an enterprise-grade ranking app, fixing bugs and design flaws that come up along the way.
Welcome to the second installment of my “Real Coding” series, in which I’m aiming to develop an “enterprise” ranking application in about two weeks, working only for one Pomodoro per day. If you want to read more about the requirements or my motivation for writing this series, make sure to check out the first part of the series.
I will do my best to keep each of the posts as separate from the others as possible so that you don’t have to read everything way back to get a grasp of what’s happening. Having said that, let’s take a look at the code that was left after the previous Pomodoro:
To give you some context, this was all written in the last 5 minutes of the previous Pomodoro, so it was not really thought through. Rather, I wanted to get to a starting point for further work.
Instead of getting straight back to code, I started this Pomodoro by writing down all the application’s functionality necessary for making any productive use of the application. The purpose of this little “exercise” is to increase both my and your awareness of what’s about to happen next in the project and to get a better perspective on the emerging domain model. In the end, I came up with the following few points:
Log in: Obviously, you can’t do much without that.
Join a ranking: Since last time, I decided that you need to “join” a ranking to be able to play matches. It seemed like a better choice if the application was to be used outside of a single company.
Add a match result: Rankings without games make no sense.
Confirm/change the match result: As said before, the players should confirm their wins/losses before any ranking adjustments are made.
View the current standings: I guess that’s the whole point of the application.
Being entirely convinced that the joining functionality is ready, I set my eyes on adding a match to the ranking. I started off with the simplest possible implementation:
Since we’ve got an if statement, with a negation and exception in here, I decided to write a little test for this functionality, especially given that I messed this up a while before. (To be entirely precise, the test was the last thing that I wrote in this Pomodoro, but this order makes more sense from the article’s perspective).
I’m not entirely sure whether this enum is the best way to represent the final score, but it was the first thing that came to my mind, so I went for it. Right now, I’m thinking about changing this to some kind of a numerical score. We’ll see.
Also, I decided to ignore the requirement of supporting both solo and team games for now. I’ll try to get the application working for solo players and only then focus on supporting teams.
To be honest, I hate using enums like this for some reason. It just doesn’t feel right. At the same time, there’s only so much that can be done in 25 minutes, and this seems to be just good enough for the purpose. Anyway, suggestions for improvement will be highly appreciated!
Feel free to disagree with me about that, but it feels like a good decision for now.
With this in place, I was finally ready to start implementing the confirmation method. As you can see below, it’s not really complete yet:
Basically, that’s the point when I ran out of time for this session, so that’s the code — at least until tomorrow. If you see anymore lurking bugs, missing requirements, or design flaws, please feel free to mention it in the comments. If I don’t change my mind and all goes well, the next installment should be pretty exciting, as we’re about to recalculate the player ratings after confirming a match result. Stay tuned!
P. S. I uploaded the project to GitHub if anybody’s interested in seeing the two source files in their entirety!
