Starting a brand new project is always great. You don’t have big classes, you don’t have too many dependencies, the tests run fast and there aren’t technical debts. But after not too long, projects become bigger, tests get slower, dependencies get outdated, and then you have a legacy codebase.
The goal should be to find ways to remove or at least minimize these problems. But how to identify them? If you work with Ruby on Rails, the list below contains a number of tips that could help you do just that.
Never break the build
The most appropriate way to avoid breaking the build is to create separated branches and Pull Requests. So, if anyone breaks the build by mistake it must be fixed before merging the changes into the branch
Keep your dependencies up-to-date
This includes the Ruby version, server packages (especially security updates) and the gems your project uses.
If you’re running your app on a VPS, you can likely create a image with the current state of the server, launch a new server instance, update your OS and Ruby versions and then you’ll be able to test if everything is still working well before finally updating your DNS to point to your new server instance.
Also, you can do something very similar if you have a Load Balancer, basically removing one of the servers, testing and then re-including it.
In order to update your gems, you can run
bundle outdated, which allows you to see the outdated gems, which is very useful. Once you’ve got all (or only some) gems updated, you should run your tests and see if everything is still working as expected.
Rails best practices
This is a website with a list of the good practices and also a code metric tool to check the quality of Rails code. It generates a report (available as HTML) and it’s recommended to be used in any Rails project.
Rubocop is a code analyser, based on the community Ruby style guide. It can either generate a report with stylistic problems in your code or it can auto-correct certain offenses (experimental feature). Use git after the auto-correct to check if the changes make sense.
Simplecov is a very popular code coverage analysis tool. By using it you can see the coverage across your test suites and have a HTML output with the results.
Transpec is a very useful tool to convert your specs to the latest RSpec syntax. The results are very satisfactory. As well as Rubocop, you should use git after the the conversion to check the difference and see if everything makes sense.
The longer you wait, the harder it will be, so don’t wait too long. It’s never too late though. A good practice is to use a project management tool (Trigger is an excellent one) to create a recurrent task to remind you from time to time to review your entire codebase using the tools above.