Sometime back I got a green grass project. The assignment was to implement a proprietary protocol over HTTP in Perl.
I chose to use Catalyst.
Having worked with mod_perl and Apache a lot in the past I thought it would be a good idea to use this too and the integration with Catalyst would be a walk in the park and expectedly working out of the box.
I started coding like crazy, doing semi-TDD and getting a lot done.
I was implementing a protocol, which was to be versioned and if the protocol was to have changes it would require a lot of work, not now what would come, I decided to let the controller reflect this so a new version of the protocol would only require a new controller – all of the used components would have to be revisited to the extent they would be influenced by the protocol changes – this seemed like the best approach at this time.
When wrapping things up examined all the code it struck me – the code base was a mix of OOP and procedural programming.
I had coded the application using what felt natural, I only implemented what was absolutely necessary. I isolated components for reusability where I found it useful – which is part of a long term plan to refactor a large part of the code base at work.
Which brings me to this list:
- TDD is good
- TIMTOWTDI is good (OOP and procedural mix?)
- Coding only what is necessary is good (LEAN?)
So having a large code base being a mix of OOP and procedural code, I refactored to OOP only keeping procedural code which was in external components regarding these as a hybrid sort of mixins.
The newer version new being dominantly OOP, using some common design patterns, looked more promising from a long term maintenance perspective.
I was much more satisfied with this new implementation, but I am still thinking much about the process and what actually happened.
A good architecture is of course important and the OOP refactoring did introduce a lot of code, which was only related to the actual OOP implementation and as such had nothing to do with solving the problem.
The evolution of a Python programmer comes to mind.
Am I doing enterprise programming when something more simple would suffice for solving the task or is the enterprise level completely okay, since the code is expected to live for a long time and maintenance is an important factor.
Back in school we were using a Danish book on OOAD and one of the things I took with me from that book was the authors thoughts on setting up some prime directives for your project.
Examples of prime directives could be:
- It must be fast
- It must be maintainable
- It must be correct
- It must enforce integrity / be atomic
- It must be secure
- It must be easy to use
- It must be extensible
Please feel free to make up your own.
So your project could have 1-3 prime directives, this would assist you in making decisions on:
- Architecture
- Implementation
- Testing
- Time/Projecting
I often think that project managers are a waste of resources and waste according to LEAN should be removed – okay, jokes aside.
Using the approach mentioned above developers are could be somewhat fitted to make their own decisions based on directives (most developers are quite clever, responsible and happy people), without a project manager and perhaps even without an architect – perhaps just a fellow developer or two to do code reviews with.
Looking at the project I was working on, I could defined the following 3 prime directives:
- It must be secure, since we are transporting sensitive data (SSL takes care of most of this part)
- It must be extensible, the protocol is the product and future changes should be able to be implemented without too much hassle, still predicting the future is hard and often wrong anyway, but be prepared at least)
- It must be atomic, the protocol handles requests, if these fail we should be able to roll-back and notify the client
So what prime directives are not important in this case:
- Ease of use, it is a machine to machine protocol
- Correctness, is touch directive, of course all computer programs should be correct, but please not that by correct in this sense I would use this directive if calculating prices or something else requiring calculation
- Must be fast, speed is not important in this case
So my tests should be implemented to ensure the following:
- We implement the specified protocol
- We are secure (I have decided just to assert that we are using SSL and not plain HTTP)
I could spend a lot of time testing extensibility, but I decided not to, I trust that my architecture and implementation supports this – since I have no idea of what extensibility requests could come.
The project is almost done, the project has most certainly given some food for thought, which will influence my next project. Hybrid implementations seem to come quite naturally, but I wonder if I am the only once coding this way.
The project later ran into some serious trouble, I will get back to that in a separate post, where I will also elaborate on the topic in this post.
0 Comments.