1. Lets play TDD (AKA rethink some patterns)
Some of you are probably already aware that I follow James Shore Let's play TDD series. After last episode I started to think about usual design and 'The Best Practices" that I use everyday at work. Why? Because if you're going to follow his videos from the beginning, you are going to see my comments every now and again, where I'm bitching about his design.
I especially didn't like his dollar class (value object used across whole application for calculations and rendering), up to the point that I've decided to branch his repository (everything is hosted on github), and fix it. Trigger for that was making Dollar class responsible for rendering itself onto swing components.
So after picking up a recording tool, setting project to work in Intellij and changing layout to more familiar, maven structure, I started to refactor. It took me 3 or 4 attempts to discover that James design had truth in it. I still did not like it, felt wrong (still does), and was totally different from all I was used to, but that was the first time that I thought about shutting up and just letting him do his job. On a first occasion I asked him to add persistence to his application, and watched how he solves that problem.
In last episode James started to struggle with what I waited for: how to be consistent with his current design, don't clutter VO with too many methods and don't expose internals of Dollar class at the same time. He ended the episode with question to us, watchers, on how we would approach this problem. I still think that moving parsing string out of VO to external factory class would be a good idea. There we could add two way conversion from Dollars to some universal format, most likely to String (as we want to write the value to text files and to text fields). Later, if needed, we could add formatting object to e.g. display negative values in different form.
But that's not what going to happen. I've seen in comments idea that he should persist only user inputs. After reading that I felt cheated, and that James is going to do something wrong, again. But after second thought I had to agree that it is a good option in this case, and fits well with how the rest of the application is designed. It's even extensible, in boundaries described by James in first episodes. So although I feel bit cheated, about James slipping from what I've assumed to be a corner, in the end I feel like a winner. I may observe that different approach, and I still may disagree with it and search for shortcomings of the solution. And finally, the biggest win for me: I started to rethink all the patterns that I'm using in a day to day work.
Thanks for that Mister Shore (and to the all commentators as well).
2. My quest for knowledge
As you probably know I've moved couple months ago to UK to work in ProQuest. If you haven't heard about it, then please check out my previous post.
While coming here I promised myself that I'll shut up and will try to listen more, especially that there are many, much more experienced people around. It's not easy as I disagree with many thins but I try to first see the bigger picture and ask why some things are done this way. Often it makes sens ;)
I should mention that any big change I let through peer review process. Thanks to feedback from other developers with much more experience in this code (and with programming at all), I'm able to observe how other people approach my problem and what they think about my ideas.
Working in PQ gave me a lot already. Enough to make this post go through long corporate approval if I would try to describe it, so I'll just skip to next point ;)
3. Open source and Pair programming
Following on mentioned experiences, recently I wanted to join some open source project. Warsaw JUG had a great timing on that, as Michał Margiel proposed to create software (link in Polish) for one of Polish conferences, Confitura (again, Polish link).
Sadly it took some time before he responded to volunteers and I already agreed to do Pair Programming with a good friend of mine, with hope that he'll be able to use that in his master thesis. So every Tuesday and Thursday we are obliged to show up and write some stuff. As a motivation tool, we agreed to pay small fees to wikimedia foundation or one of animal shelters, if we won't show up. But as it figures, they are unnecessary as we've been doing more informal/unscheduled sessions than the planned one :)
What I've learned from that?
My friend is coding a small financial application, that he's preparing for our other friend. He want to do it as fast as possible so he often cuts corners, IMO, in a bad way. However those session reminded me that sometimes simplest approach works well, and it is possible that it will be developed faster (initially), and actually may work better than well crafted solution.
Despite breaking many sacred rules (like encapsulation, using wishful file parsing, etc) what he created works. What's worse (for my ego) it works better than things that I proposed after first glance at code that was already there (e.g. parsing input files by regexp instead of relying on magic numbers).
Task done by application is fairly simple, parse input files, do some calculations and write the output of calculations into spreadsheet. Bread and butter of almost any application that we write, right? It's a standard application, with small exception tat it won't grow when is done.
And who am I to tell if that solution is worse then mine. They both works, and as there is no need for maintenance my approach is just over-engineered. I just feel like an idiot sitting in ivory tower, shouting why we should do this or that, when in fact those things won't ever be a problem. Same as with James Shore application. They both picked the right hammer for the job.
Don't get me wrong, I'm not going to advise you to start using public fields, violate DRY, single responsibility, or other basic rules. Those recent experience, helps me to take another step back and take a look on applications that I wrote/designed from bit other perspective.
In both cases (Lets play and PP coding) they are not over-thinking the solution. Features and solutions on how to implement are being introduced Just in Time.That is something I need to try out, although I don't know how yet. When I'm writing code it's like moving small parts, one at a time, from big drawing board inside my head, and placing them in the IDE. Breaking that will be hard, but I'll try at least once! :)
All of us want to change something in our application. That's natural, we are constantly learning. If you don't see way of improving your older code, then most probably your doing something wrong. When coding on daily basis in same environment with same people, it's easy to start improving our very specific style. But there are many people who want to and actually share their knowledge. Go out and check out, maybe someone will inspire you in very same way as James Shore inspired me to skip finishing drafts of other posts and write this one.
In 2012 I hope to change my style. I don't know how. In 2011 I was playing with different techniques, this year I want to learn at least one new language starting with coffescript/node.js (yes, js is a new language for me. Other than making things appear and disappear I don't do much with it ;)). I look forward to that and hope that it will affect my style at least a bit.
I also set myself resolution to write more often, so I hope that at least those 2 I can keep :) Till next time