I am not big on New Year’s resolutions, mainly because if you need to change something, don’t wait till the new year, just make the change. While I was driving home from vacation, stuck in traffic, I started wondering what the development teams I work with can do differently in the coming year. Thinking about what we should focus our energies on, I came up with some “resolutions” for the new year. As with any resolution or goal, not all are needed to be completed or followed, but as a developer, if you can accomplish any of these, you will improve your development skills and also help teach the developers that follow you.
Be the Computer
Yes, I had to include a Caddyshack reference. Although I am not talking about golf, but instead about the idea of going through the code, line by line, just as if you were the computer.
The past year I’ve heard developers say, “This is what should happen” or “I assume the code is doing this.” But what is really happening within the code? Do you understand what is happening?
If not, then use an old technique and “Be the Computer.” Walk through the code as if you’re the computer.
That means having no preconceived notions of what should be happening and no assumptions about what the variables are. Go line by line and read the code.
Be the computer and ask: “What will happen when the data has X value? What will happen if it has Y value? What will happen if the value from an API is null?”
Get a sheet of paper, keep track of what your data variables are, and think through what is happening – just like like the computer. However, this is easier said than done.
From this exercise you will gain insight into where you should put logging statements, where you should put your breakpoints when debugging, and hopefully understand the code better.
Manual Tests
As developers, we have gotten to the point of writing our code and if the project builds, then we say it is good. We depend on the automated unit or integration tests to point out problems. But I am of the opinion that is not enough. You need to test your code and see how it truly behaves from an end user’s point of view. Take time to test other features of the application to ensure you did not break those features and that your feature works in conjunction with the rest of the application.
By manually testing an application, you will gain insight into what the end user is looking for and how the application works as a whole. Do NOT only focus on your change.
Write at Least One Unit Test
What? Isn’t everyone writing unit tests these days? Sadly, no. There are many excuses why developers are not writing unit test cases (don’t want to add the necessary plumbing to old projects or under tight deadlines).
Take the time to write at least ONE automated test case. This will force you to rethink how you write your code and encourage you to write smaller methods and modules. You might end up refactoring some code to make it easier to read and follow.
At the end of writing one unit test, you should get an idea of writing cleaner code.
Write at Least One Feature or Class Using Test Driven Development
Not everyone has embraced TDD methodology for many reasons. It is a different way of thinking and developing code. It requires you to plan your classes and methods a little more. But in the long run you “should” get cleaner code, more testable code, and code that accomplishes only what is needed.
I can hear developers saying, “I don’t want to use TDD, I just want to get the code done!” Fine, but answer these questions:
- Did you write any unit test to ensure the developer behind you did not break your code?
- Oh, so you plan on coming back later to write your unit tests, but how long will that take to refactor to make it easier to test?
If you use TDD just once, you will get an idea of how to structure your code to be easier to test, read, and be cleaner.
Document More
Oh no, documentation? What? Why? I am a developer, my code is self documenting!
I not talking about documenting the code, but focus on the testing of the application. When you add a feature, document how to test the feature. Make it step by step, detailing the results of each step. Create a simple spreadsheet for your application and update it with each new feature.
Make it a living document that can be used in future manual tests and can be easily passed over to your QA or Product Management team.
If the feature changes and steps change, update the documentation.
Write something to help the person behind you get an idea of what is going on and how to test the feature.
Conclusion
Developers, test your code in the New Year! Delve into your code and understand how it is “supposed” to work, then write some small automated test cases to verify how it is working. Manually test the systems from an end-users point of view, helping you to see the big picture.
If nothing else, make a bowl of popcorn and watch Caddyshack.
Happy New Year!
