Posts about software development written by Nick Pachulski
A vanity metric looks good on paper but doesn’t inform future strategies. It falsely increases confidence. Code coverage can be a vanity metric. 100% test coverage means that the test suite runs every line of production code. That doesn’t mean it exercises the code’s entire intent.
Most of what I’m gonna say here has already been said really well by my favorite speaker, Sandi Metz. The Don’t Repeat Yourself (DRY) principle is overemphasized and misapplied. When you need a couple of lines of code that you’ve already written, copy and paste them. Seriously.
Some function components expand to manage a range of responsibilities. Tracking which parts of the function body relate to the task at hand gets harder. Use well-named hooks to separate concerns out of the function body and into their own files.
Try and keep names concise. Keep a thesaurus.com browser tab open while working. Type in phrases to get single word synonyms. You’ll learn some useful terminology and get better at writing more maintainable code. Good names convey purpose, so if a short name just won’t do, sacrifice brevity for clarity and camel case a whole sentence.
I’m almost ashamed to say this because I was once so proud of it but here’s a confession: I don’t always test drive my code anymore. But the lesson learned from strictly only writing code which contributes to the passage of a failing test lasts: Stay focused and do as little as is required. You’ll have less work today and someone - maybe you - will have easier work later.
Many of us split development work into segments called user stories. User stories deliver value. There should be no point at which a story is completed and no new value is delivered.
The goal of this guide is to help teach you how to keep your repository’s history clear.
The reason for having automated tests is to know whether or not code works. Working code fulfills product requirements.
Let’s test drive an even number function
When I was introduced to the concept of squashing commits, I had a difficult time accepting it. I had been using git as a commit history time machine and I didn’t like the squash workflow because it reduced my time machine’s granularity.