Profile Your Future App

So, you have the opportunity to work on a Ruby on Rails app.

Perhaps you are a potential new company employee, a freelancer, or even a consulting company. Regardless, you will probably want to get an idea as to “how well” new development on this app is potentially going to go before you fire up your editors and start coding.

It would be nice to be able to have a look at the code before deciding to take on the job, but commercial codebases are typically private, and would probably require annoying things like NDAs to take a peek, if that request was even entertained in the first place.

So, what information have you got to go on to ensure that you’re not entering a potential minefield without being able to access the code itself? The word of someone in the organisation telling you that they “take testing and code quality very seriously”? They might be telling the truth, but it’s probably best to let the app itself tell you that.

Here’s a list of things to ask about to get an app to tell you its story without divulging (all of) its secret sauce:

The Gemfile

A first simple litmus test of code care can be found in the Gemfile, so see if you can get a hold of it to see things like:

• Are the gems grouped correctly?
• Do the gem entries have any kind of versioning?
• Are there any comments explaining what each gem is and what is does, and if necessary, why it’s there?
• Are there any outdated/obsolete gems?
• Are there any locked-at-specific-version gems? If so, any comments as to why?
• Are gems you prefer/don’t prefer being used?
• If the Ruby version is enumerated, is it the latest version? If not, any comments as to why? (If the Ruby version isn’t enumerated here, ask what version it runs)

If, for whatever reason, a Gemfile can’t be examined (maybe it contains “business intelligence”…), then probably the next best artefact to get would be the output of $ bundle outdated, or perhaps a dependencies report from an online service like Gemnasium if the app uses it, so that the current general maintenance levels of the app can be ascertained.

The README

Documentation seems to be the necessary evil that always gets pushed to the bottom of a developer’s priority list, consequently meaning it rarely gets done. In the case of the README file, poor or no documentation can cost hours to weeks of stalled onboarding time just getting an app up and running, with further time being potentially wasted on solving the problems already encountered and solved before by other members of a team. Therefore, it provides value and is worth keeping as a living document, so see if you can get a copy of it.

If not enumerated explicitly, ask someone about:

• The last time the document was updated
• The last time anyone had used the document to set up the app on their local machine
• Are all the installation/setup steps enumerated?
• Are all potential known gotchas included?

If you can’t get a copy of the README for “business intelligence” reasons, then it’s worth at least asking the questions above, and perhaps linking to a good README example and asking if it covers similar ground.

App Stats

Get a hold of the output of $ rails stats ($ rake stats), which can help answer the following questions:

• Just how big is the app?
• Which areas of the app does most of the code live? Does it seem to chunk around certain areas like controllers or models?
• What types of tests have been written/focused on (eg I’d be concerned if most of the tests are unit tests with few/no integration tests)
• Probably most importantly, does it look like there are enough tests written? (see the Code to Test ratio metric)

Test Metrics

Get someone to run the test suite and forward you the output:

• How many tests are there?
• Do they all pass?
• Are any pending? Why? (In my experience, pending tests never seem to find their way to becoming passing tests…)
• How long did the test suite take to run?
• Are there any code coverage metrics? What percentage of the tests are at least touching the code?

If the app uses the SimpleCov gem, see if you can get the HTML report generated after the test suite has been run. It’s the coverage/index.html file in the app.

If you have reservations about anything you see in these reports, ask questions, since there might actually be reasons for any perceived issues.

Code Style Checking

Does the app use Rubocop or some other tool (like flog or reek) to analyse code style? If not, ask why not. If so, get a copy of:

• The output of the command that runs the analyser (eg $ rubocop)
• The configuration file if available (eg .rubocop.yml)

The command output will show you whether effort is being made to ensure good code style is being adhered to and that the codebase speaks with “one voice”. The configuration file will assist in helping you understand what the current team thinks is important regarding code style. Use the configuration file as a basis for questions and conversation points with any current app developers.

Efficiency

Database Efficiency

Is the app database being modeled efficiently? Get the immigrant gem to find out. Request an output of its $ rake immigrant:check_keys task to see whether the app is missing any of its foreign keys.

This is probably the easiest item in this list to fix due to the gem being able to fix this automatically though a generated migration ($ rails generate immigration AddKeys). There might be a reason that a foreign key was left off a table that Immigrant says should be there, so use the output as a talking point.

Query Efficiency

Check the Gemfile to see if the Bullet gem is being used to check for n+1 queries, and ask a current app developer whether it’s being used in the test suite to make sure no inefficient queries make it to production.

Security

Does the app use Brakeman or some other tool to scan for potential vulnerabilities? If not, ask why not. If so, see if you can get a copy of the HTML report of running the tool ($ brakeman -o brakeman.html).

Due to the sensitive nature of the information on the report, some organisations may be reticent to provide this output, especially if running the tool shows some potential vulnerabilities. However, if the report shows no vulnerabilities, then organisations should probably make it a point of pride to provide this information.

Slightly related to app security would be management of app entry points: are there routes that lead nowhere or unreachable controllers? The traceroute gem can determine this, so ask if you can get the output of running $ traceroute on the app.

Other Points

• Ask whether the app has a Continuous Integration (CI) build process? If not, ask why not, and advise very strongly to get one set up.
• Ask whether any cloud-based application metric services like Code Climate are used. If so, request screenshots of information like the App grade point average (GPA), code coverage levels, and security reports.
• If the app you’re asking about doesn’t use some or any of the gems outlined above, don’t be afraid to at least ask that they be added in so you can get the information you want, as it won’t be just you that benefits from any additions made.

As a developer, if you’re not provided enough information to make a decision about whether you want to work on an app or not, it doesn’t hurt to ask for it, and I hope that the above list serves as a potential list of enquiry. You’ve only got so much time in your life to work on apps, and you want to make sure you’re enabled to do your best work and enjoy doing it. After all, developer happiness is a core tenet of the Ruby (and Rails) doctrines!

As an organisation, I think you should consider enabling data about your app to be available to anyone that asks, both internally and externally, and make it a point of pride to show that your team has been able to craft it to the highest standards measurable.

The plethora of profiling and analysis tools that Rails devs use everyday during development can help introduce an app to a potential developer, and market it as something that has been created with care, has value, and is worth the time of the best people it can get to make it even greater and secure its future.

Are any profiling gems missing from this list? Leave a comment and let us know!