One of the most difficult parts of software development is adapting to change. It’s a guarantee that the concepts, ideas, and possibly the point of the program that you are writing will change several times before it’s actually done.
If you have ever heard the buzzwords like Agile, Scrum, Extreme Programming, or anything similar, then you have put some time into writing software that adapts to change. Any programmer serious about the craft has at least heard about it, but few have actually mastered it (and neither have I). Designing a program that easily adapts to change is a very difficult task. However, there are a few good ideas I have found that help create this kind of software at a team level:
- Spend more time on design! Seriously, spend a few days or weeks on it. Time put into simply designing the software and not touching the code itself is time well spent. The better your design, the less pain will come your way down the road when the product is getting ready to ship.
- Think about what type of changes could come in the future. What would need to change in the system to let these new features exists? The smaller the effect on the entire system, the better.
- Step back from the requirements of the system for a moment and ask yourself why the system is designed in a particular way.
- What is going to happen when you run out of time (which you will)? Where do you think shortcuts will be made?
After designing a system, spend a few days (yes, days) thinking about possible additions to the system. Don’t just rush into coding up the system after you have one working solution. With these ideas, think about how the system would have to change to accommodate this new idea. It really doesn’t matter if these additions are realistic, feasible, or something that no one would really want in the program. If it’s difficult to add to the current system, then maybe the system should be redesigned to accommodate it.
The other trick is really just refactoring– but taking it to the extreme. Any and every chance to refactor some code to make it more readable, useable, and simpler, should be taken. Don’t let confusing, complicated code stick around in the code base just because you have more important things to do, or you didn’t code it yourself. If the code doesn’t make sense or is difficult to understand, get with the programmer who wrote it, and make it simpler. At the very least, understand what caused the code to become so complex and avoid that path next time. You’ll save yourself a ton of time in the long run of the project, and by making the code simpler, it will be much easier to change later on.
‘Anytime you find yourself looking at a class’s implementation to figure out how to use the class, you’re not programming to the interface, you’re programming through the interface to the implementation. If you’re programming through the interface, encapsulation is broken, and once encapsulation starts to break down, abstraction won’t be too far behind.'[Code Complete: A Practical Handbook of Software Construction, Second Edition]
Basically, this quote says if you have to look how a class/method/function works to figure it out, you’re doing it wrong. Proper design hides this information well so that once it’s written, it can be taken for granted. This is an excellent time to refactor and think about how the code really should be structured.
What ideas and concepts do you use to create adaptable software?
Reference: Coding for the Changes You’ll Have to Make Next Month from our JCG partner Isaac Taylor at the Programming Mobile blog.
Simple and cool !!
Keep going !!