Vanguard Coder

Simple Life of a Keen Developer

The Anemic Design lives

leave a comment

I was practicing a design problem on applying different types of gift and item-category vouchers to a shopping basket with some edge scenarios. The problem shouted out Visitor Design Pattern, which would’ve been a fantastic solution. However, there is a certain level of influence you have depending on recent experience. The key problem stood out was that the voucher should tell the shopping basket how much discount it can give based on its contents.  Separating algorithms out into separate classes could lead to Anemic classes that hold information rather than serve any functionality.

As a result I read up someone’s twitter comments:

“When adding new methods to existing classes ask out loud “Is this appropriate?””

“Make abstractions at the last possible moment & only if they exist in the business, just because concepts seem similar doesn’t mean they are” (I used abstract voucher to derive concrete vouchers)

“Favour explicit code and more concrete classes over awkward abstractions and the quest for a DRY codebase ”

At the end, architecture could be anything, the key thing is to improve with refactoring and new functionality being added in.

Written by zkashan

May 18th, 2012 at 9:43 pm

Posted in Uncategorized

Tagged with ,

Test Drive .NET Development with FitNesse

leave a comment

Test Drive .NET Development with FitNesse by Gojko Adzic

Reading through this book, I made it a point to put ear marks on pages that I think we can use to improve our tests in FA (and potentially Trumps). As I read through a lot of pages near the middle of the became ear marked. This includes suggestion that quick-fit tests should be run seprately (which can be done in the existing environment as FA tests were refactored 2 iterations ago, and thus reduce our waiting time from 6+15 minutes to just 7 minutes) as well as making them more customer centric and readable rather than be developer oriented. This ranged from page formatting to using Do Fixtures. Some idea from this book will be implemented in the next release of my project.

This is one of the books that I would like to keep close and refer to to remind myself to use better ways of writing  Fit tests and to use this framework to its full potential as well as keep things simpler.

Written by zkashan

May 28th, 2009 at 8:13 am

Posted in Uncategorized

Fixing Pair Programming

leave a comment

I’ve noticed that once a person starts on a new project, he tries to understand the dynamics and the potentials of the team. About two weeks down, the project team evolves and each person on the project has a small subset of people that he will pair with regularly. This could limit the understand of the keep causing potential problems when rolling-off from a project as well as egos and intimidation (http://en.wikipedia.org/wiki/Pair_programming)

A solution proposed by Eric Plue when he manages his teams is via a pair matrix. This way, he does not assert each day that certain people must pair together, but instead, the team learns self discipline and tries to keep the pair matrix more balanced by making people who pair less, pair more when convenient. This method has been replicated well, as a result the team did not become static after some time, but more results were seen, and knowledge was spread. This is particularly helpful, because if a certain aspect of the code is latent, it  may become more clear as long as there is good pair rotation.

Written by zkashan

August 8th, 2008 at 11:12 am