[This article was originally published in the May 2010 edition of php architect magazine]
Over the years, learning software engineering and developing my skills in PHP, and other languages, I often found myself asking the question: “If I could talk to my younger self, when I was starting out, knowing what I know now, what would I tell him?”
I think this is a question that we all may ask ourselves from time to time; at least it’s a sentiment that I hear and feel often enough. So with that, I decided to compile that advice, as if I could talk to myself, into this beginners guide.
This guide I believe, can really assist any aspiring developer, specifically in PHP, to develop their skills quickly and efficiently, avoiding going down dead-end streets and wasting countless hours on their journey to PHP mastery.
So what is this guide and what is it going to cover? It looks at what I think are the important aspects of developing great software. That is learning proper design skills, not just focusing on code; having great mentors and a great network of contacts; using great tools; having excellent resources and documentation and some handy rules of thumb to remember. So with that, let’s begin.
Next, lets look at mentors and networking. When you’re new to anything, there’s always so much to learn and discover. Sometimes however, if you’re not careful, you can learn things the wrong way, pick up bad habits and limit your ability to grow quickly into what you really can be.
The best way to avoid this and, as my father always said, to sort the wheat from the chaff, is to find a group of people, mentors, who are excellent at what they do and learn from them. By finding the best and letting them be your guides, as Tony Robbins would say, you compress time.
They have spent hours, months and years building their skills and have made countless mistakes on the way. The best of them happily share their knowledge for all to hear, so make the best use of your time and learn from them. Some of my recommendations are:
For more great blogs, have a look at http://www.planet-php.net/ or have a browse in the blogs and websites section.
A lot of people, myself included at times, think that only coding is actually working. But that’s not the case; it’s actually just a part of the overall process. Design is the critical part. The design is where you compose your thoughts, your ideas, what you’re setting out to build and achieve with the time you are spending.
It’s also the least costly process with respect to time, human-cost, tooling-cost and maintenance. As an example, I started building a site, http://www.thelittleaussiefoodie.com, a site that, on the surface of it, looks quite nice and, to a degree, works.
But to be honest, the design was quite minimal, which lead to an implementation that felt quite hackish. What’s the net result? I’m now spending more time redesigning it properly before implementing it again. Arguably a waste of time – wouldn’t you agree?
What’s the way to learn great design? From early on, start familiarising yourself with Unified Modelling Language (UML). That way, you can take your thoughts that you have about your next great piece of software and organise them in a clear, consistent and coherent manner.
Months, even years, later you are much more likely to still quickly understand your intent and software design. I won’t get in to the details of UML here; you can find a list of links to references in the references section.
Another great method is simply taking out a good quality notepad and pen, find a quiet area and just write; composing everything in a logical manner. Ask yourself: What is my aim – this is vital. From this, everything else flows. Then cover what resources will be used, what are the component pieces of the application, will you use 3rd party software and tools, how will you deploy the application and so forth.
But whichever way you go, I strongly recommend a logical, methodical approach and system of personal organisation. Basic stationary, such as ring binders, notepads, pens, post-it notes etc are relatively cheap. I highly encourage, though I never did it for years, to make sure you organise yourself and stay that way.
The last thing that you want to be doing is wasting design and development time looking for your notes and where you put things or re-doing work unnecessarily because of broken concentration.
This is a big thing! You can write in any language only so well if you just stick to the lexicographical constructs, like if/else, switch, for, while etc. When you engage in design patterns, you’re designing more re-usable, scalable and efficient code. There is a plethora of design patterns for almost any problem that you are likely to encounter; from database access, file manipulation, output formatting and application control delegation.
Remember, you’re not the first, not by a country mile. The problems that you encounter when developing will have been encountered many times before. Don’t overly waste time re-implementing what’s already been solved. To get a solid grasp on patterns, I suggest reading:
These will really get you going.
We’ve all been there before; doing the same task, over and over and over again. You think to yourself, this is such a drag; isn’t there some way of automating this so I just click a button and the PC takes care of it.
Well, if you find yourself doing the same thing more than twice, get serious about automating that away! A senior developer, Gavin Sigley, I worked with years ago, gave me this advice: “anytime you write the same piece of code twice, stop! Wrap it in a function and call the function over and again, as it’s obvious you’re repeating yourself“.
Now whilst this is not universally true, the point is fair. Remember, if you’re writing the same thing repeatedly, you have more code to maintain and validate, equalling more effort and higher development costs.
Another aspect of automation is server-side, for example, application deployment. Some years ago, I used to deploy applications via ftp, GUI ftp at that. Hours would pass as I sat there, uploading files and directory’s at a time – by hand. Mistakes would inevitably occur: copying the wrong file to the wrong location, over-writing files by mistake and so forth.
Wanting to end my pain, I decided to automate this with a combination of bash and rsync; two freely available, high quality tools. The logic was the same every time, so it was silly to do it by hand? I can’t say how much time and effort was saved by abstracting the logic in to a simple script and then just kicking it off whenever I needed it.
Now I know there will be a number of people shaking their heads in disbelief, but well, I’m happy to share some home truths in the hope you won’t repeat my mistakes. Always look at what you’re doing and ask yourself: Can I automate this? If you can, please, endeavour to do so; or talk to others and find out what they do in similar situations.
Development is one, long, journey of learning and growth. A canny Irish developer I worked with in Sydney, Australia said: “Matt, you’ll never stop learning mate – not if you want to continue in this game“. So one of the best things that you can and should always do, is to acquire the best quality documentation and have it readily available.
This can be in many forms, but books, whether electronic or physical I find to often be the best – but that’s a personal choice. Whatever you prefer, just have it handy. With the proliferation of devices like the iPod (touch), iPhone, Blackberry Curve/Bolt and Kindle; there really is no excuse for not being prepared.
Doing a quick search of Amazon.com, or perusing the books section on PHP|Architect magazine, will return a plethora of possible contenders for your attention. With so much possibility, where should you start? One of my best university lecturers, Stephen Smith, offered this advice – understand the lexicographical constructs intimately – then choose your language. I wish I’d taken it more to heart!
With that, first get information that teaches you the fundamentals of development and design, then refine the focus into PHP. Have a look at:
I’ve provided a short recommended reading list below, broken-down by section.
Books aren’t the only great resource. There are a host of great blogs, websites and podcasts available. A simple search on Google shows this. Specific to PHP, here are a number of great links:
Blogs make it easy to keep in touch with what’s going on, what other peoples opinions are on a diverse range of topics and ideas. You can keep abreast of so much, so quickly, with so little effort. You can take snippets of what other people do and have done and see if it works for you.
Given that there is so much information, and you have to stay ahead of the curve, you need tools to help you do that quickly and efficiently. So start collecting lots of RSS feeds. Then, you can find quickly what you want and disregard the rest. What’s great is that tools are common and free. Google Reader is a personal favourite. Simple, free and available anywhere. But there are a host of others, such as:
Here’s a selection of the people that I follow:
Of course, there are so many more, but this will help you get started.
One of the great things with PHP is that it doesn’t matter if you’re coming from a Linux, Mac OSX or Windows background. PHP will run just fine on all three and there are a host of great tools and toolsets for each one. You don’t necessarily need a lot of money, nor expensive hardware to begin. This is one of the, many, reasons that PHP is one of the most popular web development languages.
Whether it’s code editor’s, administration tools for SQL databases, file management, version control, bug tracking or build management, there’s a host of enterprise-grade tools to meet the task. You can take the route of everything from the command-line, which truly builds exemplary skills, or you can combine the command line with superb GUI-based tools which put so much at your fingertips.
Here’s where, as the saying goes, the rubber meets the road. These four areas are crucial to rapid developmental progress. They are: software design, version control, continuous integration and proper documentation.
Version control is one of the fundamental recommendations I make. If you do not believe me, the first time you overwrite a day’s worth of work, or that brilliant algorithm, I believe you may start to see the merits.
Version control makes it simple to develop in a team, see changes that have occurred over the course of development who made them and why; rollback unwanted changes, professionally track bugs and make versions of your software. What’s more, when excellent tools are available on all major platforms, with excellent documentation, for free, it is an absolute must as part of your development arsenal.
Even if you learn nothing more with these tools than: add, checkout, commit, diff, history, list and update; you will be off to a good start. Now many people might disagree with this baseline; but, sadly, some people do not even learn this much. Don’t have sleepless nights trying to figure out how to get your code back that was over-written.
If you’re happy to implement subversion, take it one step further, integrate version control with Trac. Trac, as the Trac website states, is “an enhanced wiki and issue tracking system for software development projects”.
Trac provides transparency in development for a team of 1 or 10 or more. Commits can be seen by the entire team; Commits can be linked to project tickets. Tickets, or job cards can be managed and assigned to team members and co-ordinated around a professional work-flow, from design, to implementation to user-acceptance-testing.
There are other tools such as CVS and GIT, which are readily available; but my personal experience is with subversion, so that’s the one I personally advocate. For more information, check out the subversion and Trac websites at: http://subversion.tigris.org/ and http://trac.edgewall.org/
Testing is a task that can often be left till either the end or not at all. But testing is crucial. No developer, not even the most experienced, with the best toolset money can buy, does not make mistakes. Everyone Does! It’s a fact of life.
So that’s why testing is essential. PHP has a host of great testing tools, including PHPUnit and SimpleTest. There are many different views and approaches to testing, some recommend test-first development, some test-periodically. But so long as you test, then you will be a better developer.
Unit testing provides a baseline of software quality. When you have this baseline, any changes in the codebase can be checked against it. How often do we all hear of developers, in attempting to fix an existing bug, create more. Now unit testing will not stop you creating bugs, and it will not find all of them, but it will aid you in determining if the latest change breaks existing work.
Want to make the process simpler? Through SVN hooks, have your unit tests run every time a commit is made; why not manage running your tests in your favourite IDE, such as Eclipse or TextMate. A number of them integrate very well to save you the effort.
Even better, why not let build and deployment tools, such as Phing and phpUnderControl manage running them for you. With that, let’s move on to Continuous Integration.
Now I must admit that I am no expert at continuous integration, but people I trust are; and they highly recommend it. What is it? Well, I’ll quote Wikipedia:
“Continuous integration itself refers to the practice of frequently integrating one’s code with the code that is to be released (often this is the trunk, but that is not necessarily the case). The term ‘frequently’ is open to interpretation, but is often taken to mean “many times every day”.
If you get this far, you’re really becoming proficient. If you’ll remember my earlier admission on using a GUI ftp client and doing everything manually; well this is the complete antithesis. With continuous integration, you have a professional tool-chain that runs your unit tests, tracks code coverage, manages moving your code from development, through testing to staging and to live and builds your product documentation.
Now I can only speak for myself, but to build professional software, you really need all the tools you can get; built into a high quality tool-chain.
I hope that this guide will be of assistance to you. I don’t expect everyone to agree with everything I’ve said and please do not just take it on face value. But do take it as a guide and test it. If it works for you, keep going and improve on those areas. I’d love to know how you built on them. If it does not work for you, learn from that, but continue learning, experimenting and growing.
To you in your journey, I wish you all the very best of success.