It is a well-known fact that PHP is a language that lends itself well to rapid concept-to-prototype development. Unfortunately this leads to prototypes finding themselves performing the role of stable production code. Chances are the prototype code is not exactly as stable as it should be.
I recently found myself in this very situation. I was tasked with building an entire application with a release schedule of three days. Obviously the three day timetable was something that would put my normal in-depth analysis and testing in jeopardy, but even more frightening is that this rapid release would most assuredly require that prototype code would become production code. Throughout development–which was by far a prime example of why design while coding is a bad choice–I was painfully aware of the need to refactor almost every line of code in the entire application. Okay, that is a bit of a stretch. Not every line needed a rewrite but some decisions were made against good conscience with the intent of refactoring at a later point.
Because of this decision I am now slowly improving the code while still adding new features into the mix–features that did not have an immediate need but still should be in application–which leads to a very rapid “agile” release schedule for point release (e.g. 1.1, 1.2) with about two weeks in between each release. This may not be anything new to a lot of people, but for my clients at the university this is a new and very different approach.
I am also, as a result of the original time constraints, committing a cardinal sin against my beliefs regarding testing: I am now adding tests in to my project because I felt I did not have time to write them before. This has already led to numerous junctions where I wonder what, exactly, I was thinking when writing the code under test and a subsequent refactor of the code to match the new test that will fail. Obviously I have now branched into TDR (test-driven refactorization.)
The point I am trying to make is that while it is possible to use PHP in the manner to develop applications at a rapid rate, the “refactor factor” that allows us to do so is more of a problem than a benefit. Putting off test development, putting of good design, and promoting prototype software into a production environment is not something that should be a daily occurance, if it occurs at all.
No related posts.
One Trackback/Pingback
[...] the original post here: The Refactor Factor Related ArticlesBookmarksTags The Difference Between PHP Echo and Print Few other web [...]
Post a Comment