The Book: Pro PHP Refactoring

Posted on 05.11.2010 by Kim N. Lesmer.
I just finished reading the book Pro PHP Refactoring by Franvesco Trucchia and Jacopo Romei. The book itself should be refactored - it's not pro at all. The book is an attempt to take the guidelines from the famous Refactoring: Improving the Design of Existing Code by Martin Fowler and turn them into PHP refactoring principles.

While Martin Fowler's book is a really valuable and professional piece of work I can't say the same for Pro PHP Refactoring.

While I can respect and admire the attempt of the authors in trying to explain and display the theories of refactoring in a pure PHP context the result is really bad.

Several of the theories of refactoring is misunderstood and the examples in the book are just not serving the purpose of refactoring.

Real refactoring is about improving existing code without changing the underlying functionality, but Pro PHP Refactoring manages to present refactoring as something affected by personal preference. Meaning: The examples used doesn't improve the design of the code as much as it just demonstrates another way of doing things that isn't necessary better.

In chapter 2 the authors compose a list of "bad smells in code" and lists "procedural code" as a bad smell.

This is a big mistake because procedural code has nothing to do at all with bad design or bad smells in code.

The authors of "Pro PHP Refactoring" is biased towards only writing object oriented code.

Many very successful projects around the world consists exclusively of procedural code. Projects like the Linux kernel, xBSD, Git, The Apache Web Server, and even the Zend Engine itself is written in C - a pure procedural programming language!

Procedural programming is a programming paradigm, derived from structured programming, based upon the concept of the procedure call. Procedures, also known as routines, subroutines, methods, or functions contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program's execution, including by other procedures or itself.

Procedural code is not a "bad smell in code". The term "Bad Smell" related to programming seems to have been coined by Kent Beck on WardsWiki in the late 1990s. Usage of the term increased after it was featured in Martin Fowler's book about refactoring.

Determining what is and is not a code smell is often a subjective judgment, but listing a specific programming paradigm such as procedural programming as a "bad smell" is just plain wrong and unprofessional.

What Martin Fowler does in his book "Refactoring: Improving the Design of Existing Code" and what Franvesco Trucchia and Jacopo Romei completely fails to do in "Pro PHP Refactoring", is to list the commonly known "bad programming habits" known by experience to cause problems in the long run.

Some examples of bad smells in code as presented in Wikipedia on the topic is:

  • Duplicated code: identical or very similar code exists in more than one location.
  • Long method: a method, function, or procedure that has grown too large.
  • Large class: a class that has grown too large.
  • Feature envy: a class that uses methods of another class excessively.
  • Inappropriate intimacy: a class that has dependencies on implementation details of another class.
  • Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class.
  • Lazy class / Freeloader: a class that does too little.
  • Contrived complexity: forced usage of overly complicated design patterns where simpler design would suffice.
  • Excessively long identifiers: in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture.

In my humble opinion the authors of Pro PHP Refactoring has missed out on the main benefits of refactoring and are actually presenting examples in their book that are dubious at most.

The authors seems to present object oriented programming as the solution to all programming and design problems, which of cause has nothing to do with the subject of refactoring.

If you consider purchasing Pro PHP Refactoring my advice is this: Don't bother! Buy the original book on the topic by Martin Fowler and convert the theories into PHP yourself.

If you have any comments or corrections feel free to email them to me.