One of the key factors for success as a software developer is to work smarter, not harder. These posts contain tips on how you can do just that.
One of the key factors for success as a software developer is to work smarter, not harder. These posts contain tips on how you can do just that.
I make use of Windows Terminal a lot. It’s great for having multiple different pieces of work open at the same time.
Over a decade ago, a project manager and my work approached me with a proposal. You see, we had a minor quality problem, and he wanted us to do better.
The Liskov Substitution Principle (or LSP) is one of the big five SOLID principles and one that is often poorly understood. Yet, ignorance of the LSP can lead to subtle, expensive, and sometimes embarrassing bugs.
When developing systems that must wait for key things to happen (often, things that are outside their direct control), we need to consider how long we’re willing to wait for an answer.
Long ago, before storing things in the cloud was commonplace or economic, I used an online mirroring tool to replicate all our family photos between my desktop PC and my wife’s netbook. This was both effective and painful - here’s why.
Coming up with the right name for a method can be a challenge even if you’re sure you know exactly what it should do. All too often, I find that part of the reason why I’m having trouble choosing a name is that I haven’t really decided the purpose of the method.
If you have a utility class in your current code base, there’s something very important you should do - even before you apply any of the techniques we’ve discussed previously.
Sometimes you’ll find a method on your utility class that’s only used once - or only from a single consuming class. This frequently happens when a developer genuinely believes the method will be generally useful and should be available for reuse, but is wrong.
Sometimes your utility class will contain methods that smell strongly of feature envy, prompting you to relocate them onto an existing class. This is a much simpler cleanup than introducing a semantic type.
Following on from our discussion on extension methods, another technique you can use when eliminating the dumping ground of your utility class is the extraction of buried semantic types. This is possible when you find a set of closely related methods with linked semantics.
Think about the larger projects you’ve worked on during your career. Did you have a dumping ground for odd pieces of functionality? Perhaps a utility class or even multiple multiple utility classes? It’s a very common thing to see a utility class in any codebase of reasonable size, especially one that has been around for a while.