Anyone who knows me knows that I’m a huge fan of unit testing. At least in theory. Unit testing is something that sounds great, and is great – if your tests are already written. But it sucks if you’re trying to build a test suite. In fact, building a test suite is one of the hardest things a programmer can do. It’s probably why I’m really bad at it (despite my advice to build one anyway).
Part of my problem has always been that I never really understood how to use the tools that are offered by PHPUnit. As a result, I’ve avoided writing tests for a long time.
Too many developers struggle with their object oriented programming skills. Concepts like abstraction, single responsibility principle, unit testing, refactoring, architecture and SOLID seem out of reach. You wonder how you can grasp the concepts. You buy books. You attend conferences. You go out of your way to try and learn. Nothing works. You feel stuck.
When I sat down to write Mastering Object Oriented PHP, I recognized that people needed an easy to understand resource. They needed to be able to read the book, understand the material and be able to use it. But books have an inherent flaw, and one that I think needs to be addressed.
Have you ever had this situation before? You have a problem to solve and no idea how to solve it. You want to sit down and do it “the right way”, but “the right way” involves writing tests, designing objects and generally working out something that’s far more complex than you need to get a working prototype. And so nothing gets done.
I’ve been there myself. I recently needed to prototype something. As I sat down to work on it, I had absolutely no idea how I was going to write the component I was working on. And so, I started working – without a plan, without writing tests, without designing an architecture, and without really knowing how the component was going to end up.
When I was first starting out in development, I thought that writing code was pretty easy. It took me a while (and a long learning process) before I realized that writing code is harder than it looks. Looking back on some of that first code, I wonder how it ever worked, how I avoided a serious security problem, and what I was thinking about when I wrote some of that code.
Experience is the way that most of us learn how to write code, but experience is a lousy teacher: it gives the lesson after the test. Here are some ways you can improve your code writing right now.
Two craftsmen make chess sets. Beautiful chess sets. One craftsman uses old style tools: chisels, files, hammers of all sizes. His preferred material is stone; he carefully carves the pawns, the queen, the rooks and the knights with exquisite detail, like his father, and like his father’s father. Another craftsman uses more modern technology to melt and mold metals. He uses fire, molds, and tools that can withstand tremendous heat and pressure. His boards are different colored metals. His pieces are just as exquisite, just as delicate, just as beautiful as the other craftsman.
Each year in December, we’re afforded an opportunity for contemplation of the past year as we look forward to the dawning of a new one in only a few days’ time. This look back at the year’s accomplishments was inspired largely by Laura Thomson’s declaration on Twitter that the Socorro team closed 1,000 bugs in 2012 – a truly amazing sum. I’m extremely proud of my team, and extremely proud of the work that we’re doing to make Firefox and the open web better.
I’m particularly proud of some of the things I’ve had the privilege to work on this year. Here are a few things that I worked on: