10 Steps to Supportable Web Applications

published on September 23rd, 2008 · more from the blog →

So I've now been developing large scale web applications for a few years now, and I thought i'd share a few points I believe every coder needs to think about.

If you're just starting out you wont know why you NEED to do these things, but anybody who has had to re-visit there own or someody elses poor code will soon tell you that it's far better to get it right and scaleable from the start than to have to go over everything and try and change it 6 months down the line.

So, in no particular order..

1) Don't rush to start

Think things through before you write it. This goes hand in hand with point 10, if you think something through to begin with and do it right the first time, it'll be easy to expand upon and improve later.
If you rush straight in you'll get half way through, get stuck and have to start all over again.

2) Plan to scale the codebase

Many problems in developing applications come from having "organic" code, we've all seen it, code that just grows and grows into a behemoth of unsupportability.
All projects, whether big or small need to be factored into well organised, scalable applications, From! The! Start!
No silly naming of functions, having a function "set()". It needs to be "set_foo()" at a mimumum so that you can have "set_bar()" as well, having just "set()" is going to get confusing VERY quickly, don't do it!
Consider using an MVC like framework, either your own, or a lightweight open source one.

3) Seperate application logic from markup

Now doing this may sound simple, but doing it *well* will inherently move you into a situation where you'll be using an MVC or a templating "engine" like Smarty.
This will look much prettier and give you (or a non-techy designer) complete freedom to change your design without touching any code that could potentially break the application.

4) Abstract.. but not too much!

I'm a great fan of abstraction, but only in the right places.
Most people soon realise they need to use some sort of database abstraction class, because lets face it, doing large updates on big tables is no fun. BUT, and this is a big one, do not use an abstraction method that can transform across multiple database engines, and the reason is simple, Use the best database for the job to begin with!
Why bother supporting all the other options? Seems silly to me. That level of abstraction will only slow down your code and make it less flexible.

5) D.R.Y. - Don't Repeat Yourself

Ah, the classic phrase, now nearly everyone has heard of this funky little acronym, but many (stupid) people still choose to ignore it.
By copying and pasting code all over your app you will have a nightmare situation somewhere down the line where you've updated one page but not the other 5 and you'll have data inconsistencies.
Not repeating yourself is so easy to do: wrap your logic up into a function and use that function everywhere, then when you need to change it, the changes are made in 1 place, but reflected everywhere consistently.

6) Throw bad code away!

This one is easy, if it's all going wrong, don't try and rescue a bad implementation, just refactor and start again doing it right, you'll appreciate it in the long run.

7) Be consistent, be strict!

If you have two situations where you expect the same behaviour, always have the same behaviour.
For example, "set_foo($value)" returns true on success and false on failure, make sure "set_bar($value)" does the same, don't return the new value of bar or an error code on failure. Then all developers will know what to expect and check for.
Also be consistent with the order of parameters to a function, the classic example is in PHP where some of the functions take function($needle, $haystack) where others take function($haystack, $needle) choose one, and stick to it!

8) Plan for change

Yes, heaven forbid, your client will change there mind and you'll have to change a feature almost entirely, some simple things that will save you time.
- D.R.Y - if you've done that it'll ease alot of your woes.
- Abstract the process of actually getting the data, that way hopefully you wont have to change too much logic, just like abstracting your markup form your logic.
- Keep summaries of data in relavent database tables, for example in a blog you might store the number of comments to that article in a field along with the post, that way you wont be running loads of subqueries on your dataset when you need to pull out a simple stat.

9) Make authentication, security and filtering easy and flexible

Nobody likes sanitizing user input or checking if someone is logged in. Abstracting this process and making it as easy as possible will ensure that you are more likely to do it every time, meaning less security holes, less code and less problems in the future. Simple functions like my PHP XSS Filtering function can help.

10) K.I.S.S - Keep It Simple Stupid

Another one of my favourite acronyms. This doesn't just mean optimizing code, it means thinking about the most logical way to implement an entire feature.
Think about what you need to achieve, then do the minimum amount to implement it. Don't overcomplicate the process, and definetly don't overcomplicate the code.
This also goes for functions, don't EVER have a function with more than 3 or 4 parameters, you'll forget what they all do, what order they go and which ones contradict the others.

Other things to consider:

Some things we can't do anything about, ignorance from developers is a biggy.
Often, nasty code will be written because the developer has no concept of how to do something the easy way, they'll make it much harder than neccessary. What can we do about this?
Refactor as you go, I don't expect people to go around re-writing whole apps but if you can see a big improvement for no compromise, go and change it, but make sure that YOU fully understand why it was done that way to begin with, otherwise you could be in the wrong.

Think about application scale, one day you may have to have thousands of simultaneous users, having robust and fast code from the beginning is your best friend. Don't be afraid to run cron jobs to do difficult processor intensive tasks if you need to, generating statistics and compiling logs of data takes ages, don't put the burden of loading this data into each page load. Instead run a cron, aggregate the data and display that instead.

With all things said and done, I understand that for some people in some situations, there will be times where much of this will seem pointless and they'll skip it to save some time, after all, we all have deadlines to hit right; but trust me, following simple, consistent steps from the start will make your life much easier, and we all like an easy life right!