We have successfully adopted the Gerrit workflow for pre-commit code review in Evojam. We believe that this a foundation of high quality of our solutions. After two years we have worked out a complete approach for the pre-commit review with Gerrit, branching model and application provisioning. Now I have realized the there is no definite cookbook for the newcomers. This led me to the idea that it may be worth to share this approach with the community. This is not totally unique but may save a newcomer a bit of time.
Performance is a complicated beast. Each step in the problem solving chain of performance issues - identification, diagnosis, rectification and verification, pose unique challenges. This post will deal with themes from the first two steps, and is aimed at teams who are already conducting some form of performance testing.
Pre-commit code review can provide some tremendous benefits: It improves quality of the final code, it helps team members to learn from each other. It also propagates knowledge about projects and best practices. But it also generates additional problems. Here's how we dealt with them.
There are three popular possibilities – jsDoc (with e.g. Google Closure Compiler), Facebook Flow and Microsoft TypeScript. First one uses comment like annotations – does not corrupt pure JS – while next two extend JS so they have to be transpiled. I will compare them briefly in a moment.
