These days, the best developers, and development organizations realize maintainability is one of the most key aspects of design. Applications, libraries and frameworks rarely if ever remain static. These developments evolve over time. This is an obvious concept, but it has been ignored more often than one would think possible. How many times have projects placed “get it out the door” over the characteristics that will contribute to a maintainable system?
Maybe it’s just me, but I’m seeing progress in this area, and I’m hoping it’s a sign of a shift in thinking, or a better connection between developers and management. Of course, this progress might just be the most recent saga in a long, slow and inexorable process that has been progressing for longer than I have personal experience. Regardless, greater acceptance of techniques like unit testing, test-driven development, refactoring, static code analysis and two-way modeling & design are excellent examples of progress. Also, the evolution and standardization of tools like defect tracking and source code control are notable signs. As well, process is getting better as it is realized that trying to make all decisions upfront, and then “just code it”, just doesn’t work.
The concepts behind these improvements have been around for quite some time already. The newest is barely less 20 years old. Mainstream acceptance and integration are very important but once that’s done, what’s next? Well we need new ideas and new goals to follow.
One opportunity that I think we are missing is the ability to leverage code change itself. One of the main purposes of unit testing is to help insure behavior, other than what you intend to change, remains constant. With good tests, you can refactor with greater freedom and success. By running tests before and after change, you can determine, within some limits, how much behavioral change you have caused.
But unit tests only cover the behavior we have defined through tests, and we find it difficult to cover every conceivable possibility. But behavior isn’t the only thing changing in this scenario. Our code is changing as well, so why is it we don’t leverage that element of change more? Sure, our source control tools allow us to diff the files, and review them that way. And we can have code reviews that focus on the changes made. But all of this is a lot of work, and so there are limits to how thorough time will allow us to be. And besides, if we could find a way to make those activities less necessary, we’d be able to focus on other issues. Or we’d just do those activities in a more focused and effective manner.
So why not have automated tools to analyze code change itself? Such tools could highlight troublesome types of changes, much like static analysis tools do for static code. But one of the biggest problems with static analysis tools is they create too many false positives. On a large project, with strict settings a static analysis tool is likely to return 1000’s of warnings. If you had a more convenient way to see just those warnings that were related to change, the signal to noise ratio would be far better.
Beyond that, code change analysis could go much further. Did you introduce side-effects to a side-effect free method? If that happened, it would be very nice not only to be reminded of that change, but also to be reminded of any instances where that method is used within a loop. Have you introduced new dependencies? Wouldn’t it be nice to see a list of those for review? Have you opened up previously unreachable code paths?
There are opportunities that go beyond analyzing the code too. Automated analysis of code profiling histories would tell us when performance degraded in a certain area. Maybe we don’t want to address it right away, but later on it may help immensely to know these trends when we go back to perform optimization.
The point is, what we’re trying to manage is change. To do that, we need to make change work for us, at least some of the time. Just as unit testing embraces the concept that what we are searching for in testing is not simply correctness, but often unexpected change, we should also embrace that the search for change within other tools as well.
0 comments:
Post a Comment