I look at the situation we have gotten into by having this problem [of replacing a large legacy application], and frankly, it is like the tech version of 'Scared Straight'. The paranoia of such a far reaching application within the enterprise that absolutely has to deploy successfully and also be very flexible to meet the needs of the future have driven me to the point of near madness in trying to make sure this thing is bulletproof, enter Test Driven Development.

He includes an example situation he recently was faced with in his code...and opted for the "easy" way out (difficult to test). He talks some about the issues, dependencies and coupled code this has created. He does, however, show a solution to the issue - passing in the dependencies as they're needed, not defining them in the method.

For me, writing custom apps in an enterprise environment is not about rapid deployment and looking like a hero. It is about deploying software with a design life of 7-10 years, because the change management involved in deployment is not something you want be be doing over and over again. Testable code with 100% coverage of unit tests, well developed integration testing, and prolific use of tools like PHPUnit & Selenium are part of the development culture because while speed is important, durability is even more critical to business.

Unless you're working on a fresh project right now, the codebase you work with most likely has such code you take for granted. And the more challenging your current assignment (or fresh project) is, the more likely it will become a legacy part as well on short notice. Since it's infeasible to fully comprehend all problems that your codebases solve, as well as all their solutions, something else needs to be done to prevent code rot. One way or the other: the code needs to be refactorable to live happily ever after.

The breaks down the steps that a unit test should follow on its most base level - assemble the environment to test inside, act on the code and assert that the output was as expected. He walks you through each of these steps, detailing what's involved and including some sample code to illustrate. He also includes a few tips on the successful application of tests like:

• Don't forget to write integration/acceptance tests as well.
• Name your unit tests verbosely.
• Write unit tests for bug fixes.
• Never change the code under test.

I went to my standard code library, developed on my own over a period of 3 or 4 years and starting piecing together a core application that I could start building on. I worked on this application diligently from June to September, and I would say in that time I had made it 70% of the way through the app. I was being relatively careful about doing manual functional tests, and I felt good about what I was doing with the application where security practices were concerned. Then 2 things happened almost simultaneously that really put a wrench in the works.

He was working on a project for several months, but due to other circumstances, he had to set it aside for a while. When he came back, he had a new perspective on things and saw lots of places in the code that things could have been done different/better. The post goes through some of his thought process and how it relates to the three "roll on", "refactor" or "re-roll" the current state of the application. He does have a reminder for developers facing the same situation, though:

The whole reason I am writing this post, other than to just get my thoughts down and help make the call, is to illustrate the importance of remembering that as developers, one of our key objectives for the client is to deliver value. This is a fact that can sometimes get away from us.

I've been there myself. I recently needed to prototype something. As I sat down to work on it, I had absolutely no idea how I was going to write the component I was working on. And so, I started working - without a plan, without writing tests, without designing an architecture, and without really knowing how the component was going to end up. You know what? The component came out working, but when I was done it was ugly. Totally ugly. The code was bad. But I had a solution, and a solution that worked.

He points out that sometimes, doing things "the right way" can stifle creativity and experimentation - two things that a developer needs to solve the problems they face day to day. He notes that refactoring is a part of their job and moving from a rough prototype to a finished product often improves this skill and can find issues not discovered before.

This does NOT mean that developers can push bad code into a repository. Nothing lives longer than temporary code; see to it that your finished code is always good.

In software development, we're spoiled. We can write a single line of code and do some interesting things. If we add a framework, that single line of code is backed up by thousands.. and can do even more impressive things. [...] I can't tell you how many people have pitched me to "rewite web2project using [framework x]." At first pass, it sounds like a great idea. We can lay the foundation for doing things "right." We can use the latest and greatest tools, technology, and concepts. Even better, we don't have to figure out all that old crappy code! It's open source so it's free anyway. Everyone wins! How many times have you looked at an application and thought "I could rebuild that in a weekend!"

He points out the "seductive" nature of this kind of thinking and some of the things that it can hide from your immediate vision. These are things like: the lessons that were learned and implemented in the current code, catch up vs new development on the project and the possibility of "killing the community" as they'd no longer know which part of the project to contribute to.

He suggests instead of worrying about a rewrite, that development groups worry more about managing technical debt in their applications and reducing that piece by piece instead.

One of the most notorious consequences of this rational associative process is that, at some point, we effectively end up creating classes that do too much. The so-called "God class" is quite possibly the most extreme and coarse example of a structure that packages literally piles of unrelated operations behind the fence of the same API, but there are other subtle, more furtive situations where assigning of multiple roles to the same class are harder to track down. [...] What the principle attempts to promote is that classes must always be designed to expose only one area of concern and the set of operations they define and implement must be aimed at fulfilling that concern in particular and nothing else.

He starts off with a typical violation of the principle, showing a class that not only handles user data but also includes the functions to work with the database directly as well (insert/update/delete). He refactors this into a few much more manageable classes - a mapping class to handle the database interaction and a "User" class representative of a true user object.

Unfortunately the first reaction to a poorly written application is usually a resounding "rewrite". Developers feel like a weight is lifted from their shoulders, as the manager hears a distant "cha-ching" sounds of money slipping away. [...] In the managers mind a rewrite means it must all be duplicated, and that's not far from the truth when we consider the salaries of an entire development team for the time it will take to rewrite the entire application.

Adam talks about some of his experience in the past with challenging applications and a typical scenario where one group in the company splits off and creates the new version while another maintains the old. He suggests, however, that refactoring may be a more viable option. While it might not seem easier to handle overall, the end results could lead to a more stable system and could take less time than starting from scratch.

Adam Culp posted the 3rd article in his Clean Development Series this week, Dirty Code (how to spot/smell it). When you read it, you should keep in mind that he is pointing out practices which correlate with poorly written code not prescribing a list of things to avoid. It's a good list of things to look for and engendered quite a discussion in our internal Musketeers IRC.

His suggestions include things like "Comments are valuable", "Using switch statements" and a few other smaller ones involving error suppression, globals and prepared statements in database usage.

In part three of this series we dealt with refactoring code for extensibility and discussed logical extensibility, modular design, decoupling, and encapsulation. In this final part of the series, we discuss what the main concerns of efficiency are for your web application and how to refactor for better efficiency.

They talk about some of the things you can do about network bandwidth usage, memory inefficiencies and processing issues (over you doing more work than you need to?). These aren't code examples - every application is different when it comes to this stuff, but it gives you some good questions to ask to fill in the blanks.

Extensible code is a piece of code which follows re-usable, logical, well-known patterns, be it standard design patterns, or normal logical flow. Modular code tends to be highly extensible and monolithic code tends to be non-extensible, but monolithic code might be more efficient, so to solve this conundrum some practices allow developing in a modular way and deploying in a monolithic way so we can get the best of both worlds. The major aspects which we are to discuss with regard to extensible code are: logical extensibility (normal logical flow and design patterns), modular design, and decoupling and encapsulation.

He goes through each of the sections - logical extensibility, modular design and decoupling/encapsulation - and for each provides some questions to ask to help you whip your code into shape.