If a software developer had all the time in the world to create a simple web form, it could be the most polished, over-engineered, beautifully written piece of software ever created. But sadly, time constrains exist, and we really need that form by this afternoon for a promise we made to a client.
Developers are constantly making trade-offs between meeting deadlines and writing good code. Good code is flexible, expandable, and concise. Rushed code tends to not be flexible, not very (cleanly) expandable, and cluttered. Rushed code tends to work though, so it ends up in the codebase never to be refactored again. And this is what I call the timeline dilemma. Because the code was rushed, it’s not written as well, so when it comes time to expand on it, more time and effort is required to complete the work. Whereas if it was written well to begin with, the new work wouldn’t be as difficult and would be easy to keep well written.
There’s nothing more permanent than a temporary fix
Always abstract and use Composition!
By far the easiest way to keep code clean is abstracting your objects as much as possible that makes sense. It doesn’t require much additional work, and it allows you the flexibility of adding methods directly to those objects instead of having oddly attached methods to objects that are only slightly related.
Further, composition is very useful in practicing separation of concepts. Keep logic localized to properties you need and the objects they relate to.
These techniques are so critical to writing code, but they’re so easy to overlook when under a deadline. Don’t overlook them though! They’re some of the simplest patterns you can implement and will help when expanding on any parts of the code down the road.
For more information on abstraction, check out my pages all about abstraction!
How important is this feature?
Some features are going to feel pointless to write in an expandable fashion. Maybe it’s some data processor that feels unnecessary and one-off. That may be true, but I’d suggest still writing it in an expandable manner! Why? You’ll likely write fewer bugs! That’s one of the nicest parts of separation of concepts, is each part should be testable independently and have clear tasks and responsibilities.
Separating a data processor into a data provider and processor components can help keep everything straight and when requirements inevitably change, you’re ready to quickly make those adjustments.
Actively making good design patterns the first goal while working on any piece of code will help you practice for larger projects and will help make sure all code you write is readable and beautifully abstracted.