Original Source: FINALINT So Says Donnie Garvich
I recently inherited a web app from a dirty, nasty, stinking contractor that claimed to be a competent enough programmer to be left alone to get things done. Unfortunately, we took him at his word. Functionally, most of the web app seemed to work at first glance. However, once the client took over the reigns and actually started using it things went downhill fast. The contractor disappeared after payment (die reputation DIE!) and I was left to try and get things working properly and performing up to snuff while the client limped along with what they had been given.
I decided to document a few of the things that I found wrong along the way. These are really just things that every good programmer should already know to avoid… but obviously some people need to be reminded (or taught).
#10 – Don’t store settings in a configuration file
When you’re writing a sizable application, things like database connections and SMTP server information will be used throughout the app. The best way to make sure your app is entirely immune to maintenance is to redefine those little bits of information every time you need them. So instead of putting them in the configuration file (Web.config or whatever) just leave them in your compiled code. Whoever inherits the app will thank you for sending them on a hunt through thousands of lines of code to change which SMTP server is being used. What’s even more fun is when the next programmer only finds 14 of the 15 places where you’ve used this code and a single instance somewhere deep in the app silently breaks hundreds of times without anyone knowing. Sometimes it’s helpful to build the variables in inconsistently concatenated strings. The repeated and more frequent interaction between the new developer and the disgruntled client will help strengthen their relationship. And if you don’t hook up that love connection, who will?
#9 – Don’t store variables in [any] memory scope
One of the great things about databases is they store your bits of information and allow you to access them whenever you need them. To make sure your app is as terrible as possible, you’ll want to be sure and access the database every time you need a bit of that information. The more common the information is that’s needed, the bigger win you’ll have by making a new database connection to get that information. Non-sensitive user information is a great use of this prinicple. Don’t worry about defining a user’s information, such as “isAdmin” to a variable and using it throughout the current request. Just query the database each time you need to know anything about the user. After all, the client paid for that database, we’d better get as much spin out of it as possible! Read the rest of this entry »
Recent Comments