The project I’m working on at the moment spins around one main domain concept. For the sake of the example I would use a class InvestmentFund.
The initial approach to the design of the InvestmentFund object was quite rudimentary but unfortunately something not uncommon in our industry.
Each field of the database table got mapped to a field in the object and there is an abundance of primitive and nullable fields.
The InvestmentFund class looks a bit like the following but 10 times larger:
I am trying to push the use of more granular and less primitive objects in our domain and I am promoting a refactoring of our core domain objects by following three ways suggested in the book Growing Object Oriented Software Guided by Tests:
A first refactoring bundled up together some of the values of InvestmentFund like the fees information. The result was a type Fee:
which transformed our InvestmentFund class in:
A second refactoring that I would like to pursue is a way to differentiate decimals that represent money and decimals that represent percentages. Budding off those type make sense but I am not sure of the best to model rates.
Do I need a general Percentage type, a more specific InterestRate type or a type for each one of my rate types like “commission”?
The latter looks a bit like what my collegue Mark Needham describes as a Micro-Type.
I will probably start with the simplest solution (a Percentage type) and see how it goes.
Feedback is much appreciated.
Today I started try to refactor a piece of code that was causing me pain.
Dependencies were tangled together, classes were getting bigger, functions and names were losing their meaning and unit tests were becoming cluttered and hard to understand.
After few hours trying to tangle this code I started thinking that probably it would have been easier if we had tackled that a few features earlier.
When you are caught in the TDD cycle red – green – refactor it’s easy to focus only on small scale refactoring and losing the big picture. Also Bob Martin rule: “You may not write more production code than is sufficient to pass the current failing test.” might be misleading.
Dan North talks of “…deferring important architectural and design decisions until the last responsible moment”.
Is there an easy way to identify the last responsible moment?
I think for now on I will stick to this rule: as soon as I start adding a feature to a piece of code I will make sure that it respect fundamentals good practices (small functions that do one thing, command query separation, small classes that follows the single responsibility principle and meaningful names). I will applly the same treatment to tests.
I will probably spend more time caring about exception handling, good object modeling and so on, on the most used and strategic part of a codebase.
In order to identify those areas, keeping track on stories that takes longer than expected and the one with more bugs, might help.
What is your approach to this problem?
In the meanwhile you should follow me on twitter here
After 2 weeks having dinner with Mark Needham (@markhneedham) I finally got infected by a mild version of his acute blogging syndrome.
The last post is from about an year ago and a lots of things happened in the meanwhile.
The most important is being hired by Thoughtworks.
I have been working on an interesting C# .Net project for a major UK comparison website. A very good first project due to the large number of thoughtworkers involved in it (More than 20).
All the usual positive aspects of TW mentioned in other blog posts are valid.
It is definitely hard working for Thoughtworks, early trains, often away from major cities and big responsibilities.
Overall it has been my best professional experience so far and I am looking forward to work with more and more thoughtworkers. I will try to help Thoughtworks grow. I’m fully committed to Thoughtworks.
I used to work in a C# .NET shop. It was a new technology I came from a C++ education and I had the possibility to receive free training and a job.
After that experience I started to work for another company, similar technology but our CTO had a Java background so the system architecture was more JEE like than .NET; we had a MVC framework developed by him and we had an almost completely stateless server side. He made me appreciate the power behind open source technologies, unix like systems and many other interesting aspect of the enterprise apps world.
I have always considered the programmer’s job an art that was not strictly related with programming languages, specific technologies or even computers. The problems solving / abstract / creative aspect is what I consider the core part of my job.
What I have noticed in most of the developers using Microsoft technologies is the lack of understanding of basic object-oriented and computer science notions. They are just people that after university bought a microsoft book, installed Visual Studio and learned to use a tool! They also tend to be Microsoft fanboy and they are completely second-level ignorant about every other alternative to their little packed solutions.
The Java world is full of other problems although I found the its vibrant community is open-minded and very close to the Agile trend.
I am quite happy now. I am no more slave of Microsoft products and I am part of community of people that love trying new things (languages, technology, methodologies) and they have a better understanding of software development and computer science.