Two months ago, I shipped a code review software called Coddee and presented it at Product Hunt Sydney. In this post, I am sharing my motivation for this project, technologies used, and some learnings.

Coddee is a free web application and is available at http://coddee.io. The code is not open sourced to enhance security for the users, but my presentation slides at Product Hunt are viewable here.

Problem with the code review

Coddee is a tool that makes it easier to review pull requests on GitHub.

During my internship as a Rails developer, I noticed a massive bottleneck in my team’s workflow due to the inefficient code review process. As a novice developer that just started, I found it very odd that this inefficiency was being condoned.

Here is the problem in a nutshell:

Before our work could be merged to the production branch, and the ticket marked done, the pull request needed to be reviewed by a co-worker. But the pull requests were hard to review because:

  1. the files in them are unstructured, and reviewer has to jump all over the files to really understand what has been done in the pull request.

  2. the pull requests often contain files that are not unnecessary. (e.g. dump files, auto-generated files, etc.) They can be safely hidden so as not to divert the reviewers attention.

For these reasons, the scenario like the following happens:

A co-worker has finally got some time to review a pull request that you opened 2 weeks ago. It consists of 30 files changed. While at it, you also fixed a couple of minor bugs that are not in the description of the ticket.

Good luck going through all 30 files, figuring out what you did and coherently explaining the pull request in a timely manner.

Solution

Coddee solves the problem of reviewing bloated pull requests by allowing users to organize the files in them.

File organization

Here is a partial glimpse of what a pull request looks like in Coddee:

I introduced a concept called Context Group to group the files in any way that a developer finds meaningful. The example above shows that a developer partitioned front-end code and back-end code into two different groups.

One can also move the files or groups up and down, or decide to hide or show an individual file. With this flexibility, the code author can make the pull request contextual once and for all.

This way, a developer can present a large pull request in a coherent fashion that is easy to understand. Doing so does two kinds of goods to an organization:

  1. Less time spent on code review means more time to code and ship new features.

  2. More comprehensible code review means less bugs slipped through, and less technical debts.

Real-time feed

Through webhook, Coddee is notified any time a pull request is opened, or updated. The changes in the pull request instantaneously shows up in the user interface.

This pull request feed shown in the picture is real-time and always shows the latest information. I feel that by integrating this feature with other services such as Slack, team members can be kept up-to-date like they never have been before.

Technology

Coddee is built with Meteor and uses MongoDB as the backend database. Everything is written in vanilla JavaScript using some latest ECMAScript 2015 specifications.

On the front-end styling side, I originally used bourbon and neat to write everything from scratch in a hope that doing so will make the app look different from all the other apps using Twitter Bootstrap.

As I went on, I gradually came to senses that I might be better off using a front-end framework because I was wasting way to much time on designing and the app frankly did not look very great.

So I tried to rewrite the front-end styling with Semantic UI and was blown away. Even though Semantic UI’s Meteor package was kind of buggy, I can’t wait to use it again in my next project.

Semantic UI at work. It didn’t take very long to code and the UI looks not atrocious.

For syntax highlighting, I used highlight.js. Since the code is presented in a html table with a row for every line, I was not able to use highlight.js straight out of the box.

I first rendered the code inside the table. When the rendering was complete, I read the code line-by-line and constructed a temporary string, syntax highlighted the string, and inserted the code back line-by-line:

function highlightSyntax(lines, leadChar) {
  var tmp = '';

  lines.each(function (index, line) {
    var lineHTML = line.innerHTML;
    // Remove preceding +, - to keep hljs from detecting it as diff
    var unescaped = unescapeCode(lineHTML).replace(/^[\+\-]/g, '');
    tmp = tmp.concat(unescaped, '\n');
  });

  var highlighted = hljs.highlightAuto(tmp);
  var arr = highlighted.value.split('\n');

  lines.each(function (index, line) {
    line.innerHTML = leadChar + arr[index];
  });
}

// Highlight syntax
var newLines = this.$('.new-line');
var oldLines = this.$('.old-line');
highlightSyntax(newLines, '+');
highlightSyntax(oldLines, '-');

Learnings

Do progressive authorization

In the beginning stage, Coddee used to ask for private and public repository access privilege when users authenticated with GitHub. I had multiple feedback from people that they were not comfortable giving all those permissions to an application they don’t know.

So I chose to only ask for public repo access when users first sign up. In the dashboard, I gave users a choice to include/exclude private repos from the repo list.

This way, there is a less friction for users to get started with the service. Then, they have an option to opt in to grant more permission. There is a huge difference between being forced to grant permissions and being allowed to opt in.

Write tests for core functionality

One thing that helped me iterate really fast and ship with confidence was testing.

Earlier in the development process, I wrote some tests for the core workflow: when a webhook is received from GitHub, Coddee should create/update the existing pull request in the database.

No matter what I changed in the back-end and how I refactored the code, I knew for sure that my app will deliver its core value proposition to the users as long as the tests passed.

I did not spend hours trying to achieve comprehensive test coverage. In my opinion, doing so is often a waste of time. But I think well written test for core functionality can go a long way to save much time and ship more features.

Conclusion

Within a few days, the organizer of the meetup put Coddee on Product Hunt (Thank you). But it did not generate much interest.

I was sort of confused because I got such positive feedback when I asked people in real life. Could it be that people are just too nice face-to-face? Anyway, I am glad that I did not go all-out, but rather shipped an MVP with minimal time and effort.

I still think that the problem Coddee is solving is a kind that is worth tackling, and that a properly implemented solution can be of value to many software developers out there.

After the presentation, I was offered a job and now I don’t have much time to iterate. Yet, I have a feeling that I might come back to solve similar problem in the future.