Software is often compared to constructing buildings and that got me thinking: How would we do things differently if we actually had to live in the code we built? I know that question doesn’t really make sense, but if you think of some software you’ve seen, how would it compare to a house? Would it be a shack, or would it be a beautiful mansion? Don’t get me wrong, sometimes a shack is the perfect domicile. Continue reading
refactoring
How to easily add a bunch of automated tests to a project that has none
If a code base is well tested and very stable, it’s pretty easy to write more tests for it. But, how do you get started writing automated tests if your legacy application has none? It’s very difficult to get started because the code wasn’t written with tests in mind. Normally, the endeavor will have you pulling your hair out. This is unfortunate because a lot of untested code desperately needs tests, yet it takes an inordinate amount of effort to write them. In this article, I’m going to tell you about a tool that you probably haven’t heard of that can help you get that legacy code base tested. It’s called Approval Tests, and here’s how it works: Continue reading
One of my favorite features of Intellij-IDEA: Call Hierarchy
This article is about a relatively unknown feature of Intellij-IDEA called Show Call Hierarchy. Most people who use Intellij-IDEA already know about the Find Usages command, but Call Hierarchy is like that command on steroids.
If you want to learn a code base, start renaming things
They say the 2 most difficult things in computer science are cache invalidation, naming things, and off by one errors. That explains why so many things are misnamed in code bases. This is a pet peeve of mine and I always try to fix it whenever I can. It’s the easiest way to to practice the boy scout rule.
I go around renaming poorly named variables and classes. It’s a win-win situation: The code base is easier to understand for the next guy and it’s easier to understand for me. When you rename something, you have to understand the code at a certain level of depth that is unnecessary if you merely look at it. The best way to understand code is to actively participate in it.
Sometimes you may think you know how a variable should be named, but then you realize that it’s used in another place you didn’t notice and you made a mistake. That little detail will stick in your head better than just looking at the method.
This is probably different enough to warrant its own post, but I also want to say you should name your servers appropriately. If in casual conversation you call the server the “HP Demo Server”, it shouldn’t be named “xfdke03.mycorp.com”. Stop making a humans build an associative map in their head. That server should be named “hpdemo.mycorp.com”.
Usually these servers’ domains can’t be changed over night and it may be risky to do so, so it never happens. In that case, I edit my hosts file so that “hpdemo” resolves to the IP Address of “xfdke03.mycorp.com”. Not the best solution in the world (the IP address can change), but it’s better than nothing.
Companies should take these complaints a little more seriously though. If “HP Demo Server is “xfdke03.mycorp.com” and “HP Prod Server” is “xfkde03.mycorp.com”, a person could accidentally do some serious damage if they had access to both.
How to write your automated tests so they don’t fail when you refactor
The main benefit of a good automated test suite is that it gives you confidence that your code is working correctly. It helps you find bugs as soon as you introduce them instead of at 3am on a production environment.
If you have a solid test suite, you can feel confident that the change you made is safe. When you have that confidence, it allows you to change the nastiest parts of your code without wondering if you broke something.
But sometimes tests can get in your way. Sometimes you’ll want to refactor a group of classes and tests will fail even though nothing actually broke. This is a bad smell and it should be avoided. In this article I’m going to teach you how. But, before I do that, I want to make sure we all agree on the definition of “refactoring”.
Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. –Wikipedia
In other words, refactoring means cleaning up the code without changing functionality. If you refactored correctly, every single feature in your application should work exactly the same as it did before you refactored.