A while ago I told a tale of two developers working together on a project each with different skill sets. Today I wish to expound on the story. When we left off the two developers were working to “break-out” a piece of business logic that had been lost in legacy, database riddled, EJB twisted spaghetti logic. The hope was to end up with a component that did what the original logic did but could live outside of the horrible EJB container it was trapped in. They worked in a separate project that would eventually be integrated with the original project.
Mr. Hot-shot, (I think we called him Cliff in the last story) thought he had everything sewn. All of the business logic had been accurately described using POJOs, the current Java programming trend. There were no direct ties to the database and he was able to temporarily divorce from his partner after providing stubbed-out implementations of the front facing interfaces that defined the high level contract or responsibilities of the business objects. Wait a minute… What the hell does all of that mean? I’ll elaborate. The business objects were create from the outside in starting with unit tests that excersized business interfaces. These interfaces were to be the main point of contact between the legacy code and the revised logic. Because they were interfaces, Mr. Hot-sh… err… Cliff could easily provide a dummy implementation of the interfaces for his partner to use in the legacy code. She could then pretend that the new objects that they collaboratively developed were there in the legacy code and continue the remainder of the project while Cliff polished off the rough edges and did the actual integration work.
Anyway, where was I? Oh yeah! Mr. Hot-shot thought he had everything sewn because everything was falling into place. He had some trouble with the integration but after that was finished it looked like the adventure was over and the new business objects were operational and acceptable in the context of the original app. Everything smelled of success. Then, a week later his partner returned with new business requirements. Actually they weren’t new requirements, rather they were requirements the two had previously discussed and left for later implementation. At the moment, and as they were presented to Cliff, they appeared new. The requirements, presetned in the form of printouts of the legacy Java source-code, were complicated, daunting and riddled in table-speak. Every setnece, every necessity, referenced some unrelated table column or foriegn key constraint. It was as if the database had somehow been fed ipecac and regurgitated all over the documents the two were mulling over. Panic stricken (because that’s how he typically reacts to the unknown), Cliff quickly dove into a frenzy of unit test coding trying to mock up some scenario that would explain the new requirements. After the dust settled he calmed and came to realize that the requirements were no different from what they had discussed originally. While the legacy logic was crazy and complex he knew that the problem itself was moderately simple. Some heavy refactoring to the initial quick dash of stoopid unit test code exposed a simple scenario that would accurately reflect the desired behaviour of the new code which would eventually be extended to color the bar green.
The main outcome of the latest adventure was a realization that most of the original code the two developed could be reused without revision to satisfy the additional requirements. That reinforced the fact that they were on the right track. Additional behaviour could be added by extending, rather than retooling the original code. The original interface could also be used, untouched in the new scenario as it was simple and made no assumptions about low level details. It reflected a very high level idea which remained constant. It was pricing a product. Overall the design remained the same, though the inner workings of some unit tests need to be cleaned and some general practices came into question. (Should they use constructor injection or setter injection?) The project was still looking good. It looked as though Test Driven Development was proving itself once again.
Can't see nothing but the source code 