Project Post Mortem

A list of good and bad decisions made in the making of MatchJS.

The Good

• Before writing a line of code, we had our project thoroughly planned and structured across the full tech stack. As a team of four engineers working together for the first time, we considered it very important for everyone to be engaged in the product roadmap/decision making process.

• We created mocks and detailed user stories to prioritize and come up with the best user flow for our application.

• We planned our file structure very carefully, with a good separation of concerns. This led to highly modularized code that could be maintained on both the front and back end. In the front end we had a folder of each angular component. Within it you would find separate files for the model, the view and the controller respectively.

• We adhered to Angular best practices (https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md). We adhered to the following rules:

  • Single Responsibility (1 component per file)
  • Defined small functions (less than 75 lines)
  • Wrap Angular components in an Immediately Invoked Function Expression (IIFE)
  • Declare modules without a variable using the setter syntax.
  • When using a module, avoid using a variable and instead use chaining with the getter syntax.
  • For modules, only set once and get for all other instances.
  • Use the controllerAs syntax over the classic controller with $scope syntax.
  • Use a capture variable for this when using the controllerAs syntax. Choose a consistent variable name such as vm, which stands for ViewModel.
  • Defer logic in a controller by delegating to services and factories.

• We created a detailed Git workflow and adhered to the rebase model. This helped us do the following:

  • Keep our commit history decluttered. Normally when you want to push your changes and you have to pull in prior changes before pushing yours, you need to merge those changes into your branch. Without using rebase, these merge commits convey no useful information to others and clutter the project history. We sought to avoid that when possible.
  • We did use merge when merging development into master. This helped us record when our development went into master (aka when we were set to release a new set of changes). This was a useful case of merge.

The Bad