10. Develop
Could
Deploy automate? Review
Merge QA
11. What to Review?
Follow coding guidelines Performant
Better coding syntax Scalable
Remove unused methods
Easy, and code Important, but depends
becomes maintainable on experience
12. What to Review?
Follow coding guides
What if we can
Better coding syntax review these
automatically?
Remove unused methods
13. What to Review?
Performance
And focus on this
more important stuff
Scalable
This is our development lifecycle for each sprint, we implement new features or fix bugs, we ask other engineers to do code review, qa will verify our changes, then we merge it into release branch, and finally deploy to production server. I think most teams using rails have a similar development lifecycle like this.\n
In the development lifecycle, some processes can be automatic, some have to be done manually. Manual works are alway easy to introduce bugs into your product, while automation makes things simple, more accurate and less buggy, so we try do processes automatically as much as possible.\n
In our development process, we write codes manually, but sometimes automatically generate code, we also wrote a lot of unit test and integration test code to run tests automatically.\n
In code review process, we have to do it manually, sometimes sitting together, face to face review, sometimes just sending a code compare link and leave comments on github.\n
In qa process, we have a continuous integration server to guarantee all unit tests and integration tests are green, we have scripts to do regression tests. Besides these, we also manually verify the product.\n
In merge process, we use the version control system, git, to automatically merge feature branch into release branch.  Only when conflicts occurred, do we need to manually fix them.\n
In the deploy process, thanks to Capistrano, we can release new features almost 100 percent automatically.\n
As you seen, we have more or less automation in every process except code review, code review is very important that it can catch most bugs and potential performance issues, but code review really depends on engineers, e.g. if engineers are familiar with ruby and rails, they will suggest opportunities to use a lot of rails built-in helper methods, and if engineers have strong knowledge with database and http protocol, they will point out where you can optimize db queries or add cache layer. But could we partially automate code review process? Of course yes.\n
Let's see what we review in general. It contains 2 parts, the first part is easy, its goal is to make code more readable and maintainable, like following the team's coding guideline, using better coding syntax and removing unused methods. The other is more important but complicated, like reviewing whether code is performant and scalable, it depends on programming experience, you will see senior engineers and team leaders spend more time on this part when they do code review.\n
What if we could review the first part automatically?\n
So engineers can focus on the more important stuff when doing code reviews.\n\n
I have built the rails_best_practices gem over the last 2 years, I created it for analyzing source code of rails projects, giving developers some suggestions to improve their code quality.\n
For example, in the edit action on top, the code reads a post from the database, then verifies the privilege by checking if the current user is the user of the post, rails_best_practices will tell you there is a bad smell in posts_controller line 5, it suggests you use scope access to simplify the logic to the bottom code, read the post from current_user's posts, if the post does not belong to current user, then a NotFoundError will be raised.\n
A similar example, in the top code, before creating a new post, it assigns the user_id from current_user. The rails_best_practices gem will tell you that you should use scope association like the  bottom code does, creating a post with current_user.posts will automatically set the user_id.\n
This is an example of a suggestion to use rails built-in helper, the code on the top reads user's login attribute then checks if it is present, rails_best_practices gem will suggest that you use the query attribute, by directly calling login? on user. \n\n
I saw more and more developers begin to use the rails_best_practices gem, someone integrated it into guard, running rails_best_practices frequently in development, and someone integrated it into jenkins, running rails_best_practices on their continuous integration server. I also saw a team building an internal system based on rails_best_practices to score their developers' code.\n
There was a chance that our team decided to pay down technical debt, you know we have a large rails codebase, started in early 2009, there are a lot of unused classes, unused methods, dead routes and old ugly code. Then I used the gem to refactor and cleanup our codebase, but rails_best_practices gem generates the local analysis result in terminal, I found it's not easy to share the analysis result with the team, and I need to contact the author of the code which you want to refactor, and discuss with them to see if the code is safe to be removed. Then an idea jumped into my mind - why not build an online code review service based on the gem?\n
So I built the web service railsbp.com early this year, just like travis-ci for continuous integration service, railsbp.com provides an online code quality check service. Every time you push to github, the code check service will be executed automatically. You can easily share the analysis with your team collaborators. ralsbp.com keeps every analysis result, so you can track the history to see if your code quality is improving or not. You can also configure what to review, e.g. if you don't care about using query attributes, you can disable that checker on railsbp.com.\n
Now I built railsbp.com integrated with github, first you need to register your github repository on railsbp.com, every time you push code to github, github will notify railsbp, railsbp will check out your source code, analyze your code quality, then generate an analysis for your commits. You and your collaborators can all view the report, then refactor the bad smells according to the report.\n
There is a railsbp service hook on your github repository admin page, after you register a repository on railsbp.com, you will be assigned a token, set the token on github hook page and activate this hook, then railsbp can receive the notification from github, check out and analyze your source code.\n
This is an analysis report page, it tells you the current commit id and commit message, lists all code smells in your repository, for each code smell it tells you the filename, line number, warning message, which commit and who introduced this code smell. The highlight line indicates this bad smell is introduced by the current commit. You can click the warning message, and it will bring you to a page which gives you a suggestion how to refactor the bad smell, and you can click the filename, it will bring you to the github file page, if you want, you can fix the bad smell directly on github. So before you ask a senior engineer to do code review for you, you can review it on railsbp.com by yourself, it helps you improve the code quality and also saves other engineers' time.\n
This is the history tracking page, the visual chart shows how many code smells in your repository historically, so you can easily figure out if your code quality is improving, there is also a table that lists each analysis result, clicking any item will bring you to the detail analysis report page.\n
It is also configurable, I understand that not all checkers in the gem are suitable for all rails projects, some rails teams may have different idea of rails best practices, so, you can configure what checkers should be activated, and turn off other checkers as you like. Here are parts of configurations, you can select any checker that you think is suitable to your team, and you can change the parameters of some checkers for your team.\n
You can also add or remove collaborators, to grant them privilege to configure your repository on railsbp.com. And for simplicity, you can synchronize your collaborators from github.\n\n
So far the gem may not be strong enough to find out all of the code smells, probably there are some code guidelines in your team that the gem can't analyze, but don't be depressed, the gem provides a way to extend it for your team by writing plugins.\n
Here I will give you an example how to write the plugin, as you know, rails provides a convenient helper method try, calling try on nil object always returns nil. I want to check the rails project to find all code that is doing the same thing as the try method, so that I can replace the manual code by using the try method. Let's build a use try checker plugin.\n
This is the test file for the use try checker plugin, it's easy to read, if I use author ? author.name : nil, or use author.nil? ? nil : author.name, then I should use author.try(:name) instead, the gem should tell me the filename, line number, warning message with use try on author, right? And for other code, there should be no such bad smell detected. Every time you write a plugin for rails_best_practices gem, be sure you write such test code first.\n\n
This is the use try checker plugin implementation code, I recommend you to read the documentation of ripper in ruby 1.9 first, it's a library to convert ruby source code to syntax tree. Here we only check ifop node in all files, it checks for the 2 cases we have written in the test code. As you can see, writing a code checker plugin is not too difficult. You can write plugins according to your team's coding guidelines, so it keeps your codebase good quality all the time.\n\n
