We’ve all written bad code. Look at the code you wrote 2 years ago, 6 months ago, or heck even yesterday. When I do this I find that I failed to follow my 4 core development principles. That’s okay we are not perfect, but we should always be striving to accomplish something more than just getting the job done when we program. Just getting the job done in a quick manner will almost always produce poor quality code that at best doesn’t scale and at worst isn’t secure.
1. Scalable
Big apps get more lovin’. If your code isn’t scalable, it probably sucks.
What do I mean by scalability? One way to look at scalability is how easy is it to add in new features to your application. The best way to create scalable code is through planning, understanding what you want the application to be when its complete, where you want the application to be in 3 years, and what other markets/tasks you might want the application to handle down the road.
I recently had a client with an application that didn’t scale in adding new features. The code was poorly written, it wasn’t object oriented at all, and it only fit one specific task. If you’re writing an application that manages clothing inventory. Why stop there? What if you might need to store additional inventory types down the line? You’re niche application won’t scale to this end and you’ll be faced with the choice of either hacking in new features or rewriting the entire application.
To accomplish scalability make your high-level objects and tables vague storing only key pieces of information. Then extend these objects and relate these tables into more niche data. Hint: object oriented code and relational database engines make this easier on you.
In rewriting the clients system I’ve made it so he can extend the software into a number of different market verticals within a minimal amount of development time (about a day or two of development). With this approach the client is less focused on development and more focused on the business and marketing.
2. Standards
Okay maybe we’re not looking for Victorian Era Standards, but if you’re not following and enforcing standards then your development process is flawed.
If you’re working on a team or just working by yourself (I do both on a consistent basis) you should definitely have standards. Your variables, classes, function names, comments, and many other aspects should follow the same standards. I can’t tell you how annoying and time consuming it is to go into someones code that didn’t follow any sort of standards. Some standards to consider are: database naming conventions (all lowercase vs a mixture), variable naming (camel case vs underscores), comments (java doc style vs some other method).
The second piece to this is enforcement. If your standards aren’t enforced then they are worthless. Now this is difficult when you are working on your own, so you have to be diligent. When you’re going through old code, make sure you add in those missing comments. In a team environment this can be enforced by peer-review, QA, or even a Development Manager spot checking random code.
3. Security
If your application isn’t secure, you’re in trouble, big trouble.
Performing basic SQL injection attacks and XSS (javascript) attacks is very easy to do. I can test a site for basic SQL injection and XSS attacks in minutes. If I find a vulnerability I can probably figure out how to exploit your system fairly quickly. There are other things to consider though, how strict are your password policies? Are you disabling unused accounts? Are you practicing security through obscurity?
Object oriented programming in PHP, through the use of setters (methods which set object variables), makes protecting against SQL injection and XSS attacks easy. Especially if these methods call a single data cleaning method (if a vulnerability is found you only have one method to fix rather than hundreds). Always pass data received from a user through a cleaner, especially if its going into a database query or being displayed out to the page. Now I could go on about preventing SQL injection and XSS attacks, but I’ll save that for another time. Instead I’ll provide you with some links. Click here for information on SQL injection and click here for information on XSS attacks.
A quick note on security through obscurity. Make form fields with obscure names so bots can’t easily hit them (obscure doesn’t mean unreadable, maybe just add an underscore to the end of the form name). Also if you have a page that only certain people should know about like an admin login, make sure google can’t find it through use of a robots file. Don’t rely on security through obscurity, but leverage it to your advantage. Don’t show hackers your front door, make them have to find your address first.
4. Error Management
Learn for your doh’s! You’re hurting yourself and your users if your not logging errors, I promise.
A lot of people don’t think about this. This is one of the first things I do when designing an application. I actually have a basic class I use for this purpose. When a client comes to you with an error, surely you want a place to dig for more information on the error. It also comes in use when in development. My applications have an error page I can go to and view errors in chronological order. Your error log should log all SQL errors (made easy if you call a single function for executing sql querries which you should in an OOP environment) .
It should also log any errors within methods. For instance if you have a method which validates data before its submitted you might want to think about logging any data that fails the validation. This is two fold, your validation could be broken in which case you will immediately want to fix it. Second, what if you find a large amount of people are missing a field in a form? The layout of the form might be causing problems in which case your designer (or you) might want to think about a better way to layout the data making it easier on your users.
Other Considerations
Don’t worry about code optimizations. Modern hardware can hold large amounts of data and process large volumes of operations. Plus in a LAMP environment the slow down is most likely due to a poorly written query or an unoptimized table which are easily fixable if you know what your doing. You should be more focused on writing secure and scalable applications then how fast you can loop through an array.
I mentioned object oriented programming a lot and by object oriented programming I mean MVC with good use of extends, private class variables and the like. If your not using OOP and MVC your code probably sucks. There are some developers out there who think OOP is a waste of time and slows applications down (see my thoughts on code optimization). These developers are either ignorant or set in the old ways of PHP. I laugh at these people and there code and so should you.
Remember this is all a learning experience and takes time. Development is a craft that you should continually be working on. as always I welcome your comments.
Tags: mvc, oop, php, practices, principles, scalable, security, standards