vsbabu.org

Where web coding falls short

My previous post about adding XML-RPC interface to our search script brought forward an interesting observation. To make the search XML-RPC enabled, I had to essentially make a copy of the script, strip out the HTML and then return the XML-RPC packets. I think the problem is with the flawed approach many programmers with web-only experience take.

The "wrong" way: Many "database driven" web programs I’ve seen are typically made as template HTML’s first. Then you plugin ASP or PHP code to show "dynamic" data instead of junk text. This is such a bad programming design. There is no concept of splitting code into reusable blocks like procedures and functions. Most of the time code reuse means putting two include files called "header" and "footer".

What I consider the right way: One should first focus on the data - that is why database designers and programmers make such good general application designers - and then work your way to HTML.

My philosophy has been that even for 100% web oriented applications, HTML is only the current interface. It will change soon, or you’ll be needed to make new interfaces soon enough. Simple examples you do during a web programming course - like guest book or feedback form - are not enough to make lasting applications.

Here is my cheat sheet (assuming that the platform is already decided):

1. Get the data requirements.


2. Analyse the data relations.


3. Your customer might be screaming out loud that they need a database driven, 3 tier architecture. Most of the time, they don’t need it. Here’s an example: A contractor designed a 40 page static site using ASP pages and an Access database backend. Customer is happy because the site is now database driven. Contractor is happy, because he got paid lot more. Customer is really unhappy when he has to update the pages using Access database! I simply couldn’t find any logical reasoning to shell out that much money for such a silly use of database.


4. Make functional or use case diagrams^*.


5. Make ER (entity-relationship) diagrams^*.


6. Think how many new requirements come in the next 12 months. Believe me, they do come. Adjust the diagrams to accomodate new requirements.


7. Is something too much of fixed thing in the ER diagram? That means it is going to haunt you later when enhancement requests come in. For example, if you’ve hard coded some status values, think of putting it in a separate STATUS table.


8. Get the above validated by the customer. If customer doesn’t care, atleast get it reviewed by someone with database design experience.


9. If you’ve not put in place a standard directory structure for your code, make it now. And document the standards. I usually use the following directories, viz., ddl for database definition scripts, dml for reports or initial data creation scripts, doc for programmer’s documentation, html for all the things that go under a web server. This way, ddl and dml scripts don’t end up under you web site and get picked up by search engines. You don’t want the world to know your database design or passwords, right?


10. Now, put the initial requirements document and check in the folder structure into any version control tool. CVS is pretty good.


11. Make the ddl scripts for building the database. Do not go and make database objects using some fancy GUI tool. Have scripts, scripts and scripts.
    Now make the database using scripts. Why? Because, 90% of the time, you’ll be asked to install this in another machine. Scripts make it very easy. Points to note here are that, don’t postpone adding primary and foreign keys, creating indexes and constraints and commenting columns and tables.


12. You now have a functional design and a database design. Make scripts to insert initial data to the tables.


13. Now, make functions to get the data out where necessary. Note that these functions do not format data. Only retrieval. I usually put all functions belonging to the same business module in one include file.


14. Now and only now, talk to the page designer and inform him/her on how to call your functions to put in the data. If you are the page designer, then the temptation will be too much to put everything in one file and then put multiple IF-THEN-ELSE conditions. This causes spaghetti code and is very annoying to fix later.


15. Test it thoroughly. Fix issues.


16. Check it in again to version control system.


17. Now, from the version control, check out only the html part, put it under a different web location (server or folder). If possible, create another database. Test this new code against the new database. This is typically called "staging area test" or may be even as "quality review". At the very least, it will expose broken links and the specific configuration you manually did while in development, but forgot to add to the scripts.

What is the big deal with all this? Almost any software developer programs like this. Problem is, there are lot of people in the web field with no prior experience developing other types of applications. They tend to focus on the presentation part and not the underlying architecture. This works fine for guest book and poll scripts. Not for bigger applications.

That is why I like Zope and Python. It is still possible to write code that looks like a legal brief in these, but these platforms scream out the value of refactoring - or making building blocks and then assembling these. Perhaps that’s why people with database experience and no web experience (not even HTML) found Zope to be pretty easy to use, while people with only web experience find it an impossible hurdle to cross!

If you are here, that means you were not bored. Repeat I will refactor my code 3 times before you start any new coding project

Jargon

Diagramming

Paper and pencil will do just fine. If you’ve already identified different blocks, putting each block in one post-it note and then pasting and rearranging the notes on the wall is also helpful - it is certainly going to be helpful to your customer. Now, if you’ve time, you can make a soft copy using any common diagramming tool out there.

There are lot of case tools out there that can help you with this. But believe me, none of them are as simple or effective as plain old post-it notes. If you master these tools, these will certainly help. But it is a steep climb. I know only Oracle Designer. I can personally vouch that it is amazingly complex - amazingly powerful too.

Spaghetti code

Usually long and ugly code that does not reveal the purpose quickly. Treat programs as programs and not as pages. You are writing code with changing control flow. It is not like a speech that you read once from top to bottom.

1. Oracle Designer is only a 'Process' Driven Tool.
   agree or disagree with the above statement

   Posted by: maz on November 4, 2004 03:45 PM