After working on high-performance projects for a while (or aspiring to), it gets easy to build things in such a way that favors performance over readability. It’s good to be reminded every once and a while that while we develop code for computers to execute, ultimately it’ll be humans who will work with them.
Mobile web applications are an interesting example. A large portion of the code is downloaded and executed by remote clients, so we tend to pay more attention to total file-size, number of HTTP requests, and ultimately how much code gets executed on the other end. If we are graded on our work, surely this is what will be looked at. There are benchmarking tools such as Yahoo YSlow and Google Page Speed which help you analyze your site and suggest techniques to apply. Naturally, everyone wants an A or a high rating.
About a week ago, I was looking over one of my projects, and wondered what the hell happened to the code; it was awful. White-space was missing in a lot of areas, CSS was condensed (in most places), and even some of the PHP caching code was pretty hackish. Since I was having to rebuild a large component of the project for other reasons, I made an effort to clean up these concerning areas.
If you can optimize your architecture or design as you go, then by all means do it. What you shouldn’t do; however, is try and remove things that affect readability in favor of performance. I think there are two acceptable ways to do this… as part of a build/deployment script, or as a filter in production. Your development copy should always be for humans. Developer time is often significantly more expensive than server resources. Let’s look at some of the various resources we need to deal with… Continue Reading →
