Code Quality Challenge — A diary — Part 2
This is the second part of a two-part series. You should read the first part first.
Before we restart
The 30-day code quality challenge is language-agnostic, but the project I’m working on is based on the Ruby on Rails framework. All code snippets used in here were gotten from this project. That said, let’s start.
Day 12 — Investigate your slowest test(s)
I already knew which tests I should look for. They were visibly slower than the rest. I ran rspec spec/ --profile to check how much slower they were:
I got 4 examples taking more than 3 seconds to run. All of them were inside a single context. Let’s take a look at them:
I didn’t need to look much to find out the problem was that the setup was creating a lot of forms for each expectation. I took a look at them and noticed that I could create all these forms only once for the entire context.
I changed this before to abefore(:context) and added DatabaseCleaner to clean my database after the context. Here what my context looked like after the changes:
I ran it with --profile again and had a nice improvement on the speed, decreasing the time of the lowest spec from 4.23 seconds to 1.45 seconds, almost 3 times faster. 🚅 🚅
Day 15 — Improve one name
One of the reasons to change the name of something is: Is the name your customers would use the same as what’s in the code?
For this question I had one attribute that used a different name on my code and another one on the client. I avoided changing this name because it’s used in 7 different models. Changing the name would make me change controllers, representers, specs, validators, etc…
But the time to change this name had come. I relied on my tests to make sure everything kept working and used find and replace to change the name across all the files I needed to change: 46 files.
Besides this great number of files, this task took me less than 20 minutes. Totally worth it. :)
Day 16 — Audit your dependencies
To complete this task I took a look at my Gemfile and made sure that I was using everything in there.
After this, I installed bundler-audit and ran bundle audit check --update to check if any gems have any security vulnerability. I got this as a result:
To fix this I just ran bundle update nokogiri and no more vulnerabilities were found.
Since I didn’t use nokogiri on this project I checked the Gemfile.lock to find out what gem used it as a dependency and created an issue there to check if they want the dependencies to be updated.
Day 17 — Tidy your open PRs/issues
As I do with branches, I always try to keep my PRs updated. Unfortunately, I admit this is not true for Trello cards. 😅 I have the bad habit of forgetting about them. But, this time, I had all of them updated. 🎉
So, I used the opportunity to poke my coworkers on their trello cards to check if they’re all updated. :)
Day 18 — Investigate long parameters list
I checked my code for methods that receive more than three parameters and found nothing. I just found one method that has three and most of them received one or no arguments.
I confess that I didn’t make this on purpose but I’m glad I did. Points to me. 👏 👏
Oh, Ben also sent an article explaining the types of coupling. It’s a good one and totally worth the time to read it. For this task, the Control coupling part deserves special attention.
Day 19 — Automate repetitive actions
On the last project I worked all the development took place inside containers. I used some aliases to start the environment since it always used two or more commands.
The current one is pretty simple so I don’t have any script or alias for it. I could create some for Git but I’m not a huge fan of creating aliases just to replace one command, although I know the benefits of it.
I’m sure when this project gets more complex I’ll have something to automate. For now, I liked one special thing that Ben told us this day and I’d like to share with you:
I think you’ll find this one quite satisfying. When I automate an annoying task, I get a little burst of dopamine each time I use my new, improved method to accomplish it. One-time effort; continuous payoff.
Day 23 — RTFM
Or, if you prefer, “Read The frickin’ Manual”.
During a long time of my experience in development, I skipped the step of reading the manual and jumped right to Stack Overflow questions. Doing this seems ok, but it’s not.
Using the manual instead of Stack Overflow is better because you have an overview of all features of the library and can learn different ways of doing the same thing.
For this project I’m using two new libraries and I have their manuals constantly open: dry_validation and Representable.
But, this task proposes something more uncommon: to read the documentation to check for unused features or anything that can improve what you already know. I confess that this is something that I almost never do.
Since I’m already trying to learn these two new libraries I’ll use Ben’s advice to get used to new commands:
Jot it down on a sheet of paper next to your keyboard so you remember to try it later. I do this often to teach myself new Vim commands. Once the new stuff is in my muscle memory, I throw the sheet away.
Day 24 — Done
And this is it. Day 23 was the last day of the Code Quality Challenge. I’d like to thank Ben for taking time to make this happen and all other participants who posted on the forum during the challenge. I’ve learned a lot with you during all these days.
Next steps?
Yes, of course. :)
I’ll get some of these daily tasks and schedule them to make it time after time. I think that doing them frequently will keep my code better, cleaner and more efficient.
What about you?
Do you have any task you do from time to time to increase the quality of your code? Share it with us, it will be nice to add it to my schedule.
