I had the occasion last friday to practise an eXtremeProgramming session, and found it really interesting.
We knew what the problem was.
We did a simple analysis by slicing the problem into 5 tasks aimed at the main classes we had to evolve
We started by coding the tests, thereby finding very interesting test cases
We implemented the code, doing pair programming, forced by the situation because we only had one computer !
We refactored the code were we could see some commonalities
The result was that we ended with very few compile errors (thanks to pair programming)
We had very few tests errors, the bar was almost always green.
One time we launched the whole application. It had an exception showing us that a limit test case was missing (initialization)
All in all, we coded in less than one day most of a feature that would have taken at least 2 days otherwise (that was the foreseeing).
I think this was easier because there was no significant architectural issue in the way.
The morale is : dont be trendy, over-enthusiast or negative but just give it a try !
21 July 2003
15 July 2003
MDA approach and Software complexity
"There is no software bullet"
This famous article from F.Brooks (1986) is always relevant today. We may think that there will be silver bullets in a near future but if they existed today, developing first-class information systems would be so easy !
This famous article from F.Brooks (1986) is always relevant today. We may think that there will be silver bullets in a near future but if they existed today, developing first-class information systems would be so easy !
03 July 2003
Saving of my blogs on freeroller,...
Thursday July 03, 2003
Finishing the metrics component, considerations on checked exceptions
My objective today is to finish this component once and for all. Then I will document the use and deployment next week.
--------------------------------------------------------------------------------
I am still wondering about the checked exceptions debate. I feel I can hear arguments from both sides:
-pro-runtime exceptions : avoid catching exceptions without doing anything valuable
-pro-checked exceptions : formally declaring what could go wrong when using an interface.
I may incline for the runtime camp, but I think the exceptions that can be recovered from by interacting differently with the interface should be at least documented (and then may be checked exceptions).
In UML2.0, there is a notion of Protocol. It is not enough to declare as contract what are the operations/ parameters/ pre-postconditions that the interface has, sometimes, the order on operations calling and parameters values are also very important. A protocol state machine can then be linked to an interface (or any classifier) in order to declare more precisely what can be its behaviour.
The conclusion of this is that: if an exception thrown by the interface contains enough information for the caller to resume the protocol execution, then it could be a checked exception.Eventually, in my case, practise is what I need,... code with both runtime and checked exceptions and the rules will follow. ($entry.pubTime) # [Edit]
Tuesday May 20, 2003
Context switching
--------------------------------------------------------------------------------
I would like to note some of my ideas regarding "Context Switching".
What is it ? It is a common fact observed by any consultant or programmer : it is quite hard to work on something, being interrupted, then to resume on the work to do.
The questions that arise are :
How is it possible to resume faster ?
Is it possible not to be interrupted ?
On the other hand is it possible to completly switch context, so that private life is not parasitized by work ? And many more question that I dont have time to write right-on !
(2003-05-20 16:30:00.0) # [Edit]
Friday May 16, 2003
Streamlined Object Modeling
--------------------------------------------------------------------------------
Here is a message I wrote on the french XP mailing list about this great book :
--------------------------------------------------------------------------------
Bonjour à tous,
Puisque l'on aborde le sujet des livres, je souhaiterais vous faire partager ma dernière lecture :
Streamlined Object Modeling: Patterns, Rules, and Implementation
de Jill Nicola, Michael Abney et Mark Mayfield
Cela sort au départ un peu de la programmation puisqu'il s'agit plutôt de patterns d'analyse objet (objets métiers, régles métier).
En revanche, lorsqu'il s'agit d'implémentation, le livre aborde une question qui me paraît très intéressante :
Quand une régle métier porte sur 2 objets (la possibilité de les associer par exemple) qui porte la régle?
C'est à ma connaissance, le seul livre qui donne des régles explicites sur le sujet. Globalement, la réponse est connue de tout développeur objet (consciemment ou inconsciemment):
celui des deux qui possède le plus d'informations pour vérifier la régle.
La vraie force du livre est de poser la question pour chacun des 12 patterns de base qui sont présentés.
J'ai trouvé, à la lecture de ce livre (en particulier les premiers chapitres), que ce qu'est "penser objet" était assez bien expliqué et ça fait donc partie des choses que j'aurais sans doute aimé lire un peu plus tôt (en aurais-je compris tout l'intérêt ? -cf les Design Patterns).
D'autre part la connaissance des 12 patterns est un excellent framework conceptuel pour analyser les objets et régles métier à implémenter.
A bientôt pour des réflexions plus XP, quand j'en utiliserai autre chose que les tests unitaires,...
--------------------------------------------------------------------------------
Finishing the metrics component, considerations on checked exceptions
My objective today is to finish this component once and for all. Then I will document the use and deployment next week.
--------------------------------------------------------------------------------
I am still wondering about the checked exceptions debate. I feel I can hear arguments from both sides:
-pro-runtime exceptions : avoid catching exceptions without doing anything valuable
-pro-checked exceptions : formally declaring what could go wrong when using an interface.
I may incline for the runtime camp, but I think the exceptions that can be recovered from by interacting differently with the interface should be at least documented (and then may be checked exceptions).
In UML2.0, there is a notion of Protocol. It is not enough to declare as contract what are the operations/ parameters/ pre-postconditions that the interface has, sometimes, the order on operations calling and parameters values are also very important. A protocol state machine can then be linked to an interface (or any classifier) in order to declare more precisely what can be its behaviour.
The conclusion of this is that: if an exception thrown by the interface contains enough information for the caller to resume the protocol execution, then it could be a checked exception.Eventually, in my case, practise is what I need,... code with both runtime and checked exceptions and the rules will follow. ($entry.pubTime) # [Edit]
Tuesday May 20, 2003
Context switching
--------------------------------------------------------------------------------
I would like to note some of my ideas regarding "Context Switching".
What is it ? It is a common fact observed by any consultant or programmer : it is quite hard to work on something, being interrupted, then to resume on the work to do.
The questions that arise are :
How is it possible to resume faster ?
Is it possible not to be interrupted ?
On the other hand is it possible to completly switch context, so that private life is not parasitized by work ? And many more question that I dont have time to write right-on !
(2003-05-20 16:30:00.0) # [Edit]
Friday May 16, 2003
Streamlined Object Modeling
--------------------------------------------------------------------------------
Here is a message I wrote on the french XP mailing list about this great book :
--------------------------------------------------------------------------------
Bonjour à tous,
Puisque l'on aborde le sujet des livres, je souhaiterais vous faire partager ma dernière lecture :
Streamlined Object Modeling: Patterns, Rules, and Implementation
de Jill Nicola, Michael Abney et Mark Mayfield
Cela sort au départ un peu de la programmation puisqu'il s'agit plutôt de patterns d'analyse objet (objets métiers, régles métier).
En revanche, lorsqu'il s'agit d'implémentation, le livre aborde une question qui me paraît très intéressante :
Quand une régle métier porte sur 2 objets (la possibilité de les associer par exemple) qui porte la régle?
C'est à ma connaissance, le seul livre qui donne des régles explicites sur le sujet. Globalement, la réponse est connue de tout développeur objet (consciemment ou inconsciemment):
celui des deux qui possède le plus d'informations pour vérifier la régle.
La vraie force du livre est de poser la question pour chacun des 12 patterns de base qui sont présentés.
J'ai trouvé, à la lecture de ce livre (en particulier les premiers chapitres), que ce qu'est "penser objet" était assez bien expliqué et ça fait donc partie des choses que j'aurais sans doute aimé lire un peu plus tôt (en aurais-je compris tout l'intérêt ? -cf les Design Patterns).
D'autre part la connaissance des 12 patterns est un excellent framework conceptuel pour analyser les objets et régles métier à implémenter.
A bientôt pour des réflexions plus XP, quand j'en utiliserai autre chose que les tests unitaires,...
--------------------------------------------------------------------------------
Subscribe to:
Posts (Atom)