Some Thoughts on Best Practices

Best practices can be great for a language like PHP. PHP is almost too easy to work in. Its low barrier of entry and high flexibility allow for many possible solutions to any given issue. Being a programmer, especially a PHP developer, you find that coming up with a fix or writing a new script is not the most difficult part of your job… finding the optimal solution is. The obvious question arises next: what makes a solution optimal? Enter best practices.

The type and level of best practices depends heavily on the development environment. If a team is made up of experienced programmers, topics like classic design patterns and performance concerns will be more important. Larger teams of mixed experience (or with a high level of turnover) may be more concerned with readability and contemporary coding styles. Amateur teams may not be interested in standards and practices until a few drastic mistakes start to cause negative business results. So, the first thing about best practices: best practices should be tailored to fit the team, not the other way around.

But why? Shouldn't all development teams use standard best practices in an attempt to find elegant patterns for their code? The problem comes in with definition of elegance and the differences between development teams. An elegant solution is a balancing act of priorities that should offer the maximum effect with minimal effort. If code reuse is important to your developers, look at don't-repeat-yourself for inspiration. If readability and easy debugging is important (which it is to me), make your code verbose and structured. From a business standpoint (which is always a priority) your coding standards and best practices should let developers debug easily, build new features quickly, and be proud of their work.

It's important that a developer is proud of their work. Happy developers are more invested in the project and workplace. Regardless of how menial coding may look I've found it to be more of an art form than an assembly line, and it takes a solid bit of creative imagination to write something good. Which brings us to the next point: best practices should push developers forward, not hold them back.

Too often best practices are used as an excuse to force a developer to rewrite their code so it conforms better. This is not all together bad, but when a developer is forced to rewrite the same chunk of code multiple times due to poor directives best practices start to act as a roadblock, not a cohesive force. Standards and best practices should flow and any rewrites should be natural, not forced.

Just like anything in development it is important to think before implementing something new. Best practices can be beneficial for development and help push the team forward. If implemented hastily and without forethought, they can slow down and demoralize programmers. Whether you're looking at design patterns, code verbosity, or front-end techniques, utilizing best practices should be done carefully and revisited frequently.