Code Quality Challenge

Into the second week of the Code Quality Challenge, we're not counting the weekend days, so we jump to Day 8.

Day 8 - Extract a compound conditional

This is best explained in a live-coding, video format. Fortunately, I have just the thing!

Please watch the first 5 minutes of this video:

https://www.youtube.com/watch?v=0rsilnpU1DU&t=13s

Makes sense and looks like a good refactoring, let's see if we can find any code to refactor. To the code base!

I started by searching for && and looked for multiple conditionals. I came across a snippet that was used a few times for validation that looked like a suitable candidate for extraction:

touched && error ? 'border-red-600' : ''

The code shows and error if the input has been touched and there is a validation error. Lets turn this compound conditional into a method with a descriptive name:

const validationError = () => touched && error;

We can now use this method instead of the multiple conditionals:

validationError() ? 'border-red-600' : ''

Better? Interesting pattern that I will use more when I spot compound conditionals in my code, gets more useful the more the conditionals you have.

Day 9 - Slim down an overgrown class

Sometimes, despite our best intentions, a few classes in our system get large and unwieldy.

Today's exercise is to take a small step toward slimming down one of those classes.

The codebase I working on is React using functional components. There are not a lot of classes to get overgrown, but there are components that do. I’m going to look for overgrown components instead and break them down into smaller components.

I found and broke down a large component into three smaller components that are much easier to reason about. A worthwhile refactor and a fun challenge.

Day 10 - Create a bin/setup script

Remember those changes we made to your README on day 1? A common area for improvement was around setup instructions.

Know what's even better than a list of setup instructions to follow? A setup script that does them for you!

I already have a script that installs our dependancies via npm but lets see what else needs setup to get the project running after a fresh clone from Git.

The app cannot run after a fresh install because of a missing file .env.local). We don’t want to commit the .env.local file into git as it contains settings that are custom to each developer and we don’t want to be over writing each other’s settings.

What we can do is create a .env.template with the default settings and copy that file to .env.local so the developer has a good starting point and a working install.

I created a .env.template added a setup script to copy the template and added instructions to the README to run the setup script after a fresh install.

A useful challenge that’s going to help on boarding new developers and moving to new machines.

Day 11 - Run your tests with your wifi off

Today's exercise: run your test suite with your internet connection disabled. Turns out, it's fairly easy to accidentally rely on an external service during test runs (I've done it many times). This won't just make your test suite slow, but brittle.

Interesting, let's see what happens when I run the test suite.

Phew, turns out we're all Green 😅 Ben Orenstein mentions using a web mocking tool to fix any problems that arise:

Chances are, you'll see a few cryptic failures when you try this. In general, I recommend reaching for a tool like Webmock to fix issues like these.

Our code base is already using a tool to mock web requests called Mock Service Worker. If you're working on a Javascript project, I highly recommend checking it out.

Day 12 - Investigate your slowest test(s)

Today’s task is to investigate your slowest tests.

On my local dev machine, the test suite takes around 20 seconds to run all the tests. I don’t really notice this as I have them running in ‘Watch’ mode and only a small subset of tests run while I’m working. I’m sure there are some slow tests in there so I’ll to a bit of research and find out how to profile a Jest test suite.

Reading the Jest trouble shooting pages I discovered the --runInBand (read all about it here) setting was applied when I ran the tests. Simply removing this flag halved the run time of my tests! Let’s call that a win 😀

Week 2 done ✓

Another useful week, I’m finding the mini challenges a great way to start the day and put me into work mode.

My favourite task this week was Day 12 - Investigate your slowest test(s), you’ve got to love increasing the speed of your test suite.

Code Quality Challenge - Week 2

Comments