Tips for developing WebApplications

So it been awhile since I sort of promised some tips on developing web applications fast. This post contains my five generic tips, which may apply to you (but then again - your mileage may vary). I’ve tried to abstract the advice and not stick to PHP development here, though it’s by far the world I know best.

1. Spend time on the data model

Too often a data model is driven by code, not careful thinking, and this often causes problems has the web application develops and expand over time. When developing a site, which needs data stored in a database (as most web applications tend to do), do try to spend some time on the data model - which tables do you need, what fields should the tables have, are the naming logical and consistent, what constraints and limitations does the data model offer.

It’s often far easier to refactor code and functionality than it is changing the database tables and fields, and it can be a tremendous help while maintaining an application if you clearly understands the data its working with.

2. Get the basics working first and fast

It often takes a while to get a complete web application finished. Help motivating yourself by getting the core working first and then add features and frosting once it’s working. By having a working skeleton, I usually find it much easier guess how much work needs to finish the various features than I do guessing the work needed to complete a section (ie. admin interface) on the application.

3. Think performance and security from the beginning

Remember to think of performance and security from the very beginning. Sometimes performance - or security - may cause you to layout the data model in a certain way or structure the application a certain way. While you may be able to add performance and security during refactoring, it’s often much harder than it is keeping both in mind from the very beginning.

4. Don’t fix the future; focus on the current needs

I don’t care about the next version. I really don’t want an infrastructure in place, which can help me build the future versions of the application. I want the features and infrastructure in place for the current version I’m working on - and frankly the features in the next version has a tendency to change before I’m ready to develop them. Too often future-proofing an application clutters the code and too often the clutter doesn’t ever come to any good use - it’s just noise once we get to the real future features of the application.

5. Naming matters

Do think of what names you use on functions, classes, variables and database tables through out the application - and choose something meaningful. A variable named $x doesn’t hint what it’s used for. Help yourself (and other looking at the code) by hinting the uses of various things by choosing meaningful names.