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.

The Bad