Skip to content

Project Post Mortem

Jump to bottom
Polina Soshnin edited this page Feb 26, 2016 · 10 revisions

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.

  • Single Page App/Thin Service Architecture. We used Angular.JS, a full client side framework that allows us to maintain controller and model state in the browser. Therefore we could generate new pages without needing to wait for a page reload by the service. Because of this, a lot of our rendering logic lives in the client and allows our server to behave more like a data API or web service. This is in contrast with thick service architecture, where any user action results in requests made to the server and HTML templates/etc are loaded as a response.

The Bad

  • We used two different CSS frameworks interchangeably (Bootstrap and Semantic UI). Mixing the two is not best practice. We also did not have consistent naming of CSS identifiers/classes.
Clone this wiki locally