You refactor too much! We’re not refactoring enough! This is a problem that, with a light touch, resolves itself.
The most common definition of “refactoring” suffers from a common weakness that creates big problems for a very specific group of people. I’d like to help.
Refactoring means rework, which means that we didn’t “get the design right the first time”. This can indicate a problem. It can also indicate a natural process of convergence towards a suitable design. Calling it “a code smell” seems to overstate the matter.
Programmers routinely give up on TDD when they try to do it in their toughest, meanest, most-valuable legacy code. I understand their impulse, but I think they’re setting themselves up for failure and ultimately missing out.
Programmers routinely ask me for advice on which kinds of tests they ought to write: unit vs. functional, fast vs. slow, big vs. small. They keep saying “integration test” when they mean “integrated test”. We have made this confusing, so I’d like to take one step towards clarifying it.
Debug with automated tests: it’s systematic, it leaves a record of what we’ve learned, and it’s boring in the best possible ways.
An example of test-first programming, focusing on adding behavior incrementally and removing duplication.
Are you worried that all these little classes and interfaces are going to destroy your system’s performance? Maybe. More often, however, the bottlenecks are caused by bigger classes and fewer interfaces causing duplication in the design.
A concise guide for going from nothing to a working nodejs environment on Linux environments.
How does one accept user input from
stdin in a Java application when running it with
gradle run when using the Kotlin build DSL? Here’s how!
Some programmers try TDD and feel blocked right away. “How do I write a test for code that doesn’t yet exist?!” I remember how it felt and what happened when I tried anyway.