Ecsyle

Common sense development in a not so common sense environment

February 21 20080 comments | post comment

I wanted to talk a bit about working in an extremely unorganized and fast paced environment, and what I have learned to keep my code from blowing up in my face. In the ideal environment we would have the luxury of a development server, a staging server, and a production server, with proper source control and debugging/qa testing. When I say server, I really mean environment, these setups could consist of more than one server, but for the sake of just writing as I think, i’ll say server. What we really have is one server that acts as both development & production. Seriously. No, i am not joking, i’m serious here. We also have management that requires work gets done in unreasonable time frames. Such as, we need a custom CMS in 2 weeks with X number of specific features that really should have been planned out and analyzed and put into some sort of project specification before we begin work. Did I mention that I also have to cutup the html and css, and create all the required templates? No small task.

Pseudo Staging

When working in such an environment, I have found that it pays to be confident. Be deliberate about your code. Think before you act, blah blah blah. Just doing something and “seeing what happens” could mean your site gets exploited or you expose sensitive to the wrong people. Not a desired result. If you need to experiment, do it outside the influence of the live site. Create a place on the site for you to test and play. Password protect it if you have to. Once you are satisfied, roll that into your live code. Remember that while you are working on the site, chances are someone is visiting. The best advice would be to setup a development/staging environment on an internal server, but if that is not an option do what you have to to simulate it.

Code Reuse

While this is the stuff of nightmares, I have learned a thing or two from it. One being that you must be able to quickly reuse and refactor code with minimal fuss. Not all projects are made equal, but most have the same basic requirements. Handling database connections, querying the database, filtering user input, and some way to quickly deal with forms. When you write a function, think to yourself: can I reuse this later? Try to decouple your functions and classes from the application. Make them as generic as you can so that you can quickly reuse them in another project. Not everything you write will be like this, but try to think ahead. Don’t tie your MySQL wrapper class to a specific database. Does it have basic CRUD functionality? Write it so that its not tied to a specific table. For a lot of my projects I have includes like html_helpers.php, or date_helpers.php. I can quickly copy these files to my new application and haven’t spent a lot of time rewriting code. Using a framework helps a lot. I was using my own built from years of coding similar projects until I found Codeigniter. It basically takes care of all the non fun, repetitive coding for you, and lets you get to the fun parts.

It will save you time in the long run, and since that is the one thing you don’t have a lot of, it’s an invaluable practice.

Since we are in the land of nightmares, I will assume there is no revision control. Which means no easy way to track your code. One very easy, and very obvious way to keep a library of code is to create a directory on your computer to store scripts, snippets, classes, etc, that you can use again later. Be sure to name them appropriately.

Commenting Your Code and Naming Conventions

When you do have to work on live code in a production environment you generally have to make quick decisions. The problem with that is that years down the road, even weeks down the road, when you revisit your clever hack, chances are it wont make much sense. Your coding style could have changed, or you just don’t remember what the hell you were thinking. All you know is that it works now, and the client wants changes. Comment your code. Don’t over do it, but explain enough so that if you have to come back to it later you will know what it means. I know that seems obvious, but I can’t count how many times I have gone back to old code and just sat there staring, silently cursing the previous developer… er, myself.

It also helps to stay consistent. If you use camel caps for class names, dont start changing that when you go back to the code. If files are named with a certain structure, try to stay with that flow.

Be smart about your variables. Be descriptive. $myvar doesn’t say anything. Yeah, its your variable. But what is it holding? Why is it there? $current_date is a good example of a descriptive variable.

Since we have no time to study code, we need to be able to quickly get in there and understand what is going on.

Don’t Reinvent the Wheel

As far as PHP goes, I generally keep php.net open in a tab in my browser. and I try to save time by finding ways that other people have done something. If I can’t find anything, well, you don’t lose that much time. Its worth looking and what you discover could help you later. Visit phpclasses.org and check the forums at devshed.com. Check out Pear too.

When management refuses to allow the use of 3rd party code, or any open source code… well, what they don’t know won’t hurt them.

Errors

Errors happen. They are going to happen. Log your PHP errors instead of displaying them. It will be an extra step when debugging, but that is far better than the alternative. Add this to an .htaccess file in your web root:

# supress php errors
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off

# enable PHP error logging
php_flag  log_errors on
php_value error_log  /home/path/logs/PHP_errors.log

Set the error_log path to someplace outside your web root. In addition to this it might be a good idea to have some logic in place to handle errors so that when the site does fall apart, the visitor isn’t looking at a blank page. This assumes you actually have time to do this. If not, this method only takes a couple minutes.

What about HTML & CSS? Javascript?

I have found that if you break up your CSS into several files, it makes it easy to reuse later. For example. Most of my designs follow a similar layout, header, footer, sidebar, and main content. I have a CSS file called grid.css that contains the basic definitions for positioning these elements. When I need to create a new layout, I just copy this base file and change a couple width values and I am done. I also have a file called reset.css that reduces everything down to a common baseline for consistency between browsers. I cannot stress how much this has helped me in getting a site working in Firefox, IE6, IE7, and Safari. I squash the major bugs once, and only once. As far as the html, I do a lot of copy/pasting. I keep a bunch of html snippets in a library on my computer.

Same thing with javascript. Keep track of your code, and you care reuse it later, expand on it, and not spend most of your time setting up the basic foundation.