I have read the original Refactoring back in 2006 but I didn’t own a copy so due to my infatuation for the Ruby programming language I decided to buy a copy of Refactoring Ruby Edition.
The first chapter introduce refactoring through a vert explicative example.
The second chapter explore the core principles and origins of refactoring.
It is interesting how refactoring is one of the core practices that Kent Beck and Ward Cunningham used on the famous C3 project and that then became part of the arsenal of the extreme programming’s practices.
Due to the iterative nature of extreme programming, a big up front design is unfeasible. Refactoring, unit testing and good object oriented practices allow to have a code that is easy, cheap and safe to change.
An another important point discussed in this chapter is when to refactor. The answer suggested is very similar to what I practice daily:
- Refactor when it helps to introduce a new feature
- Refactor when fixing a bug
- Refactor for better understanding
The most valuable tip is the rule of 3:
The first time, you just do something. The second time, you do something similar you wince at the duplication but you do it anyway. The third time, you refactor.
One last point touched in the chapter was the impact of refactoring on software performance. There are several refactorings (e.g. Remove Temp with Query) that hinder performance. Martin Fowler states that ad hoc and localized performance improvement are expensive and sometimes counterproductive. We should always remember to make the software right and easy to change so that we can improve performance later where the bottlenecks lie. I think this seek for performance everywhere is a cognitive bias that we inherited from the time when developers had to deal with few Ks of memory and expensive processor time.
So far Refactoring Ruby Edition has been enjoyable and I’m looking forward to learn how to refactor in a more disciplined and cautious way.
- In: Software Development
- Tags: ddd, extreme programming, refactoring, ruby
Value Objects rocks!
6 Mar2010
For our book club in Ewloe we decided for a change to watch an infoq video.
The team was showing an interest for DDD and few recent refactoring were towards encapsulation of logic in a few core Value Objects. Mike Wagg and Mark Needham suggested one of the talk they attended at QCon London 2009 Dan Bergh Johnsson value objects talk.
Discussing the talk one question came out, “When do we introduce value objects, right from the beginning or when certain conditions arise?”
The agreed answer was to introduce them later by refactoring although I now feel that we should introduce them earlier for the following reasons:
- They become useful very quickly
- They help express intent and help understand the domain
- Having few examples of Value Objects in the code base helps new developers pick up good habits because they tend to copy from existing code at the beginning
An interesting side effect of value objects… they make programmers happier! I saw smiles appear on the face of one pair of developers after they figure how value objects helped them avoid some dodgy code duplicated code in the view.
Another side effect of value objects is that they help you avoid null references by facilitating the introduction of Null Objects.
The only things that stops me to use value objects more is the friction that some tools like ORM cause. For example in order to have value objects field properly mapped using Hibernate it is necessary to implement a Custom User Type which can be an onerous an error prone operation.
There is also a lack of refactoring tools that helps you encapsulating one or more fields in a composite object.
- In: Software Development
- Tags: ddd, object oriented programming, ood, value objects
Budding off: Marking domain concepts in code
7 Feb2010
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:
- Breaking out consists in splitting the responsibilities of large objects in several smaller ones.
- Budding off is used to mark domain concepts in code by creating objects that wrap fields or not fields at all.
- Bundling up consists in assembling in one object a group of values that are generally used together.
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.
- In: Software Development
- Tags: .net, c#, ddd, object oriented programming, oop
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
- In: Software Development
- Tags: design, refactoring, software craftmanship, tdd
4 Months in Thoughtworks
25 Jan2010
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.
- In: Software Development
- Tags: thoughtworks
Cultural problem around .NET world
18 Feb2009
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.
- In: Software Development
- Tags: Life