November 2013
Volume 28 Number 11
Editor's Note - Standing on Principle
By Michael Desmond | November 2013
.jpg)
It’s one thing to write code. It’s quite another to write code that won’t become difficult and expensive to manage a few years down the road.
Jason Bock knows the difference. As a practice lead for app dev at software development outfit Magenic, and coauthor of the book “Metaprogramming in .NET” (Manning Publications, 2013), Bock has seen more than his share of promising software projects gone bad due to poor practices. He says it doesn’t have to be that way.
At the upcoming Visual Studio Live! conference (vslive.com), Nov. 18-22, in Orlando, Fla., Bock will present the session, “Modern .NET Development Practices and Principles,” which aims to get developers up to speed on key concepts such as loose coupling, unit testing and SOLID principles. SOLID stands for Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion. It describes five core principles of object-oriented programming designed to maximize the maintainability and extensibility of code.
“A fair amount of systems are produced rather quickly, and the cost in the long run is a code base that can be very difficult to maintain,” says Bock. “Sometimes developers veer away from concepts like dependency injection and mocking because they don’t fully understand them.”
In fact, about half the developers Bock polls fail to employ the core concepts and principles he describes in his presentation. The thing is, until six years ago, Bock himself was one of those developers.
“It took me a while to really dive in and figure out how these concepts work, but once I did, things clicked pretty quickly, and now it’s just a habit to incorporate those ideas into the projects I’m on,” Bock says. “If I can motivate attendees to take those first steps, then I’ve accomplished what I’ve set out to do.”
Adding unit tests to a code base takes work, says Bock, but there are things developers can do to ease the transition. He tells coders to start small and target unit tests at key areas, such as code that’s often accessed by other pieces of the system. He also urges developers to add unit tests to new code. This can be tough to do when the system itself isn’t geared to having unit tests in place, says Bock, “but at least it’s a start.”
Bock warns there’s “no magic answer here.” Systems that lack distinct layers and automated tests are likely to be something of a mess. Unit tests on projects such as this will almost certainly be difficult. Ultimately, he says, success is about commitment.
“You have to do it from the beginning, and you have to be committed to writing those tests,” he says. “The last two projects I’ve been on have had thousands of unit tests. Does that mean they were perfect? No. But I had a lot more assurance that when I changed something in the code I would know if I broke something or not. And I can run all of them with a simple keystroke (CTRL+R, A in Visual Studio 2012). That pays off in the long run. Even if a developer is under pressure to produce code quickly, they also owe it to themselves to have a set of tests in place so, in the future, they don’t end up in a place of despair.”
Michael Desmond is the Editor-In-Chief of MSDN Magazine.