TDD: Always code as...
TDD: Always code as...
Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- attributed to John WoodsI must say he's right. Fortunately there are usually no psychopaths hanging around on your legacy applications, but it's a good karma rule to adhere to. And you may end up maintaining your own code, which is an outcome I hope you had considered. :)
I'd like to extend this maxim with some other suggestions similar in form.
Always code as if you were pair programming (mental/social metaphor)
When we are pair programming, we have to explain what we are doing. We get a mindset that challenge our code to make it better. We never get angry at the machine or at a library's developers.
A benefit of pair programming is having a different mind that works over the same problem, so that there is a failsafe in place to stop bugs or technical debt from being introduced. But the habit of trying to explain, or at least state, a problem before solving it is a productivity booster, even if you only talk to a rubber duck. This habit is enforced by TDD too.
Always code as if you were paying your lines' weight in gold (financial metaphor)
The less code you write to solve a problem, the less code you'll have to maintain: code is widely considered a liability more than an asset (an high-level programming language is crucial here.) Moreover, there is a limit to the lines of code you can write every day while maintaining an acceptable level of quality.
You should favor verbosity only to improve readability and encapsulation: the trade-off is difficult to find here, but introducing new domain concepts as classes or methods is often a valuable asset that balances the code's hindrance, as long as they are significative for the application (e.g. customer's credit card number vs. customer's eye color.)
Always code as if you had to deploy and use your application at the end of the day
Which may be the case if it's a web application.
Portability is not a feature you can add as single user story: the best way to make an application portable, configurable, deployable and most of all working is to build it as simple as possible with these characteristics (a walking skeleton), and keep them while you expand the codebase with new features.
This practice reduces risk (chances that you may find your ideal deployment requirements cannot be met) and helps early automation of the most boring tasks, defining them clearly as soon as possible. Once the technicalities have been removed and a clean environment is ready, you will be free to work on the pure domain model.
Published at DZone with permission of Giorgio Sironi , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.