PHP Team Development by Samisa Abeysinghe
A few weeks ago I received a copy of “PHP Team Development” from Packt.
Split into seven chapters, all equally sprinkled with phrases that are disjointly written and that don’t get a point across, and some that make you think the book was written using some speech-to-text software (“Vendor locking” anybody?) , this book which “is for PHP developers who work in teams on complex projects” has given me an aversion to seeing three little words printed alongside each other (“the PHP code”).
If you have read this book you too will develop this aversion. I think Lorna Jane Mitchell and Brandon Savage who both bravely reviewed this book before me might be inclined to agree.
Published only in September of this year, I found it surprising that its section on coding standards and best practices does not suggest the use of phpCodeSniffer (for checking the adherence to coding standards, and which, incidentally, has been available in one form or the next for the last three years). Nor does Samisa suggest the use of phpUnit or SimpleTest for unit testing (Actually, nothing is mentioned for unit testing – the concept isn’t even described, nor is Test Driven Development). These tools have been around for a very long time and I was honestly startled by their ommission.
In a way that’s fine – these are only tools and the book is about team development – not about listing and reviewing each and every tool that could be used to help team members make more efficient use of their time.
But I’d rather use these tools during peer review to help highlight what a team member may be doing wrong in an efficient use of my time, than have to analyse the code myself.
So, moving on, there’s a section explaining that frameworks should also be assessed on the basis of the various open source licenses they are distributed under but the author doesn’t really explain why this is important – or discuss what the prevalent FLOSS licences are (MIT, BSD, GPL etc), or what issues they each attempt to address and what they are best suited for.
The NIH (Not Invented Here) Syndrome is mentioned and to be fair the author does give a long list of frameworks to be considered; probably the one detailed list in the book, to be honest.
PEAR had been mentioned in passing elsewhere in the book so I was expecting it to be listed in the frameworks section too, as I was expecting ezComponents to be referenced somewhere as well – but then, these are a component framework/libraries so perhaps he thought it did not belong in such a list.
To be honest, I think that is part of the problem. The book focuses on what the author thinks and his thoughts on the subject are written in such a manner, that once you put in the immense effort in trying to understand what he is attempting to communicate, that you are left with the impression that
there are no alternatives; that X & Y & Z are the true and tested ways of doing things in PHP and there are no two ways about it.
This is a complete shame.
Some other observances about this book;
- Continuous Integration is mentioned; but CruiseControl and PHP-Under-Control are not.
- Source Code Control is mentioned, and here Subversion and GIT are covered. CVS is mentioned elsewhere, under a section, and chapter, far-far-away. Mercurial, bazaar and others don’t even get a look-in.
- There is no mention of how approaches to Team Development might vary depending on whether some team members might be working remotely, Pair Programming is barely mentioned let alone suggested as one way of ensuring that each team member is learning from the other and reviewing the code that his partner has written.
- Under issue- or bug-tracking, jira and bugzilla are mentioned as two popular bug tracking tools, and although Abeysinghe states “there are numerous tools that are available, both opensource and commercial for bug tracking”, no others are listed. Fogbugz, Mantis, RT, Trac, and plenty others get left by the wayside.
Actually, I’m wrong. Sorry. Trac is mentioned – at the other end of the book; though not in the glossary or index.
I honestly considered giving up on reading this book and not writing this review. The book truly is that bad. The thought of someone paying out close to thirty euro for a book that I’d call poorly researched, badly proof-read, woefully incomplete, badly structured at worst and self-opinionated at best did force me to reconsider.
Nobody should spend close to thirty euro on a book and get so little in return.
So my oneliner opinion of PHP Team Development by Samisa Abeysinghe?
I’d seriously suggest you give it a miss – do something more meaningful with the money and buy bread to bring your team on a duck-feeding-mission.
