Designing With The Next Developer In Mind

A huge part of my role as a developer is to work with existing code that needs tweaks or changes to integrate new features. This is often not the fault of anyone but time; new features are required and old ideas are replaced. But often there’s a certain lack of forward thinking by the past developer.

This often manifests itself in a lack of comments, or in some sort of “hack” that got tacked on at the last minute to make the code work for what was needed “now.” Methods interact with each other in specific ways and there is limited modularization of classes. Procedural code is hard-coded with SQL statements and there’s limited room for future development.

This is an easy trap to fall into. When presented with a clear and concise requirements document, it’s easiest to build to the spec. But it’s not always best.

Chances are good on any system that lasts more than six months that someone is going to want some modifications or some new feature. Which means that it’s critical we design for the next developer.

What does this mean? It means appropriate commenting. It means alerting the developer to the thought process. It means providing a series of modular options that allow people to throw away bits of unnecessary logic and integrate new logic without rewriting vast swaths of code, or more code than needed.

I have five rules for development that I try to follow when I design. They are:

1. Look beyond the spec. If you’ve spent any time with the client, imagine what their needs might be in the future. What features were killed off in the development process? This isn’t a license to go ahead and do what the client doesn’t want; but what you ought to be doing is setting up a scenario where the features you recommended might be incorporated down the line. So leave hooks, places where you can work, and notes on how you might do it. Chances are good that if the client realizes they need something it will be because you recommended it and they didn’t go for it.
2. Clearly identify to-do’s and “gotchas”. Make sure you warn future developers that there are areas that are rough, unfinished, imperfect, or just plain tricky. Don’t assume that they’ll think like you – explicitly lay out your reasoning.
3. Properly implement classes and architecture. Proper object-oriented design is crucial for future developers. The ability to override your methods and alter your structures is critical to good design. Also, you should write your code in such a way that there is shared functionality as much as possible – don’t have three different places in which there are modifications made to the same fields in the database. That’s just bad planning.
4. Spend time thinking about structure, especially in the database. Too often, we design to solve a question. That’s fine – but it creates problems. For example, imagine that you’re creating a customer relationship manager, and you include one table for the customers, their phone numbers, addresses, etc. Six months later, the company wants a way to have multiple addresses for the customer – an unlimited (one:many) relationship. Now the developer must break your first table off, and edit *all* of your code for something that might have been foreseen. This could have been avoided – with just a bit of planning.
5. Pick a development standard and FOLLOW IT! When developing, it’s critical that you pick a style for your code, database, etc. – and then follow it. Inconsistencies in code, database naming, fields, columns, etc. can be frustrating and lead to big problems for future developers.

Applying these things to your code will make those who come after you happier, healthier, and curse your name less. And those of us that come after you, thank you for your cooperation.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

There are currently no comments.

Copyright © 2023 by Brandon Savage. All rights reserved.