We solve problems

  • High quality tailor-made software
  • Training courses on TDD, BDD, clean code, and refactoring
  • Consultancy and guidance
  • Help teams reach the next level in quality and productivity

Archive for the ‘Software Development’ Category



Using C# Collections

There are many ways to work with collections. We are following Microsoft Guidelines for Collections  plus some ideas that Kent Beck explains in Implementation Patterns. I've created a repository with code examples so that anyone can play with them. All the unit tests in the project are green except for two, which are red on purpose to express my surprise when I wrote them, because it's a behavior I didn't expect.

IEnumerable<T> is not dangerous itself, the surprise may come up when the variable is created via a LINQ expression (.Select, .Where ...). Then it may be the case that the query execution is deferred and the behavior of the code is totally unexpected. For this reason we try to avoid IEnumerable<T> and IQueryable<T> as the return type of functions.

Try not to expose collections as much as you can by wrapping them within objects you own which expose only the minimum domain required features. But if you have to expose the collection anyway, in our teams the convention is:

  • ReadOnlyCollection<T> is the type returned to avoid modifications to the number of elements in the collection. (Internally it's just a wrapper around IList).
  • IList<T> is returned when the collection may be modified and the order of the items in the collection is relevant.
  • ICollection<T> is returned when the collection may be modified and we don't care about the order.

Good code expresses the programmer's intent, this is why we choose from the three types above to return collections when we have to.

When it comes to parameters, it's OK to use IEnumerable<T> as a parameter because it's the most generic collection type. Although the caller could send an unresolved Linq query as an argument hidden in the form of a IEnumerable<T>, the method does not have to be defensive about it (in most cases).

Other built-in collections like List<T> are intended to be used internally, only for implementation. So it's OK for a private method to return List<T>. The type Collection<T> actually implements IList<T> so I can't find a good reason right now to use Collection<T> instead of just List<T>.

Identifying aggregates

An aggregate is particular kind of entity so first of all we need to know whether the model is an entity or a value object. Once we know it's an entity let's figure out whether it is an aggregate. A transaction should modify a single aggregate instance so the repositories should work with aggregates when possible - retrieve and save aggregates. The aggregate is an entity that may contain other entities and value objects. Some heuristics to discover which objects should be clustered into aggregates:

------ Aggregate A:
------   -  Entity B
------   -  Value D
------   -  Value E
------   -  Value F

  1. Model true invariants - an invariant is a business rule that must be consistent (transactionally or eventually) : If there is a rule saying that Value F = Value D + Value E, we must ensure that D, E and F are persisted together to always preserve that rule.
    "Aggregate is one that can be modified in any way required by the business with its invariants completely consistent within a single transaction".
  2. If we need transactional consistency in A, then although B is an entity, it doesn't make much sense to use B out of A's context, I mean, there is no reason for an entity of kind B to be modified or loaded without aggregate A - Imagine that A is an Invoice and B is an Invoice Line.
  3. Try to design small aggregates despite of the desire for compositional convenience.
  4. "Just because you are given a use case that calls for maintaining consistency in a single transaction doesn't mean you should do that. Often, in such cases, the business goal can be achieved with eventual consistency between Aggregates." 

The truth is that is really hard to model things up-front. Our current approach is to model the minimum we need for an action to be performed and then evolve. However the fact that we tried to identify aggregates in front of the whiteboard led us to a nice Context Map drawing session that provided us with a better understanding of the domain.

Source: Implementing Domain Driven Design - Vaughan Vernon

Cualquiera que esté aprendiendo puede beneficiarse de tener un blog. En la profesión de desarrollador uno aprende constantemente por lo que tener un blog es imprescindible en mi opinión. Es importante que entiendas que estas escribiendo para tí, para tu "yo" del futuro. No escribes un blog para los demás, como lo hacen los bloggers que ya tienen mucha experiencia y ganan dinero escribiendo, al estilo de los periodistas o escritores que tienen columnas en períodicos. Esto de ganar dinero escribiendo no tiene nada que ver con un blog personal. Los objetivos son diferentes. Por tanto las entradas de tu blog no tienen que ser perfectas, son meros apuntes, igual que los que tomabas cuando ibas a clase. A veces tienes más tiempo y entonces son resúmenes más que apuntes, notas sintetizadas. Tienes que ocuparte de escribir solo la información que necesitas para que tú misma/mismo seas capaz de entender lo que querías decir en aquel post de hace 6 meses. Nada más. Asi dejará de preocuparte que los demás critiquen tu blog y tardarás menos tiempo en añadir nuevas entradas.
Digan lo que te digan, tu blog es tuyo y puedes hacer con él lo que quieras. Hace tiempo despubliqué un post de crítica injustificada a Git porque me dí cuenta que no tenía sentido y que causaba confusión, fue un error haber publicado esos pensamientos porque ni me ayudaban a mi ni a nadie. Alguna gente me dijo que no podía despublicar, que eso rompía links y que no estaba bien.... pero es mi blog y hago lo que creo oportuno con él.

Lo ideal es que escribir un post te lleve máximo una hora y si lo puedas hacer en 15 minutos, mejor que mejor. Yo de media tardo unos 30 minutos. Si te va a llevar más de eso entonces te dará pereza escribir y terminarás por abandonar el blog. Es decir, la barrera de entrada que te pones para escribir, debe ser lo mas baja posible.
A alguna gente le funciona convertir notas del Evernote en posts de blog directamente.

Cuando aprendes algo, escribir sobre ello es una de las mejores formas de comprender mejor lo aprendido. Es un gran refuerzo de tu aprendizaje. Además es un tangible, una forma fácil de poner en valor la inversión que haces estudiando. Por ejemplo si lees un libro técnico y escribes un post comentando cada capítulo, asimilarás mejor el libro y tendrás un resumen estupendo al que acudir cuando haya que recordar.
Escribir te obliga a buscar un poquito más de información para despejar pequeñas dudas que no te habias planteado hasta que tienes que explicar lo aprendido.

Como son tus propios apuntes, si en el futuro necesitas recordar cómo se hacía algo que ya resolviste y que documentaste, te será más rápido recordarlo leyendo tus propios apuntes que volviendo a leerte varios hilos de StackOverflow. Yo me he arrepentido varias veces de no bloggear ciertas cosas.

Una vez que escribes sobre una idea ya te la quitas de la cabeza, tu mente se libera de ella y tienes hueco para otras cosas. A veces estoy deseando de escribir un post para que las ideas que me han llegado queden guardadas en algun sitio antes de que se me olviden. Así le dejan hueco a otros nuevos pensamientos y no tengo la mente dando vueltas a lo mismo, una y otra vez.

Intenta escribir tus pensamientos creativos y positivos. Las críticas negativas no te ayudan ni a ti ni a nadie, esto te lo digo despues de equivocarme muchas veces. No obstante lo mejor es que te equivoques tu mismo.

Como efectos colaterales de tener un blog (recuerda que no es el objetivo sino un efecto colateral) a veces conoces gente interesante y en los comentarios del post se producen discusiones muy enriquecedoras. Por eso recomiendo configurar plugins como el de Disqus para que las personas que comentan sean avisadas cuando alguien respnda. Otro efecto colateral es que se te pueden abrir nuevas oportunidades laborales. Te encuentra gente buscando resolver problemas sobre los que tu has escrito. Demuestra que eres una persona que se preocupa de su aprendizaje y que tiene una trayectoria de esfuerzo. Mi blog me ayudó a conseguir mi trabajo en Dublin cuando me fui sin nada, me ayudó más que tener un título universitario según me dijeron los entrevistadores. Pero recuerda! no escribas un blog porque quieres cambiar de empleo! porque no es así como funciona, solo funciona cuando sucede naturalmente. Sino te pillarán vendiendo la moto.
Otra cosa buena es que no tienes que repetirte tanto en ciertas conversaciones, puedes animar a la gente a que lea un post tuyo cuando se trata de un tema que ya estas cansado de hablar.

Para empezar hay muchos servicios gratuitos como Blogger.com o WordPress.org donde en cuestion de dos minutos tienes el blog creado. Mas adelante puedes comprarte un dominio propio e instalarte wordpress o lo que mas te guste. Si estas planteandote programar tu propio motor de blog, está bien, pero hazlo independiente de escribir tu blog, es decir que empieces escribiendo en wordpress mientras te programas tu blog y luego migres. Porque sino puede que nunca arranques a escribir.

Este post parece ser más para los demás que para mí, un poco al contrario de lo que cuento en él... sin embargo el verbalizar por escrito estos pensamientos me hace comprometerme más conmigo mismo a escribir con más frecuencia en mis dos blogs. Verbalizar tus pensamientos en voz alta o por escrito, aumenta tu compromiso contigo mismo, mucho más que si es un pensamiento interno.

Si te animas a iniciar un blog, sientete libre de dejar un comentario en este post con el enlace al mismo, yo me alegraré de saberlo.

Este post seguramente será actualizado con más pensamientos.

Among other qualities good tests should be easy to read, quick to understand. When the test requires complex data structures to be sent to the SUT or to be part of a stubbed answer, it takes longer to read. Moreover those structures use to evolve as the production code does causing too many changes in the tests in order to adapt them. An indirection level in between the test and the production code helps improve readability and ease of maintenance. Builders come to the rescue. I often overload builder methods to support several data structures and then apply the conversions internally.

As an example, this is the setup of one of our tests before the final refactor:

  1. [Test] public async void
  2. raise_multiple_choices_event_on_equipment_selection () {
  3. SetupViewModelWithMockService();
  4. var selectedEquipment = new Equipment { Code = "PR" };
  5. var oneEquipment = new Equipment { Code = "PR1"};
  6. var otherEquipment = new Equipment { Code = "PR2"};
  7. var equipments = new List<Equipment>{ selectedEquipment, oneEquipment, otherEquipment };
  8. var multipleChoices = new List<CompulsoryCombinationChoice> {
  9. new CompulsoryCombinationChoice(new List<CompulsoryCombinationItem> {
  10. new CompulsoryCombinationItem(oneEquipment.Code, CatalogItemTypes.Equipment)
  11. }),
  12. new CompulsoryCombinationChoice(new List<CompulsoryCombinationItem> {
  13. new CompulsoryCombinationItem(otherEquipment.Code, CatalogItemTypes.Equipment)
  14. })
  15. };
  16. ACatalog.MockingDependenciesOf(vm)
  17. .WithEquipments(equipments)
  18. .ResolvingCompulsoryCombinationsAs(multipleChoices)
  19. .Configure();
  20. /* act ... */
  21. /* assert ... */
  22.  

Imagine how ugly it was before the "ACatalog" builder. And this is the test after the builder was overloaded to supply a more comfortable API:

  1. [Test] public async void
  2. raise_multiple_choices_event_on_equipment_selection() {
  3. SetupViewModelWithMockService();
  4. var theEquipment = "PR";
  5. var equipment1 = "PR1";
  6. var equipment2 = "PR2";
  7. ACatalog.MockingDependenciesOf(vm)
  8. .WithEquipments(theEquipment, equipment1, equipment2)
  9. .ResolvingCompulsoryCombinationsAs(
  10. MultipleCompulsoryCombinationChoices(
  11. equipment1, equipment2))
  12. .Configure();
  13. /* act ... */
  14. /* assert ... */
  15.  

Productive Pair Programming

The title of this post is redundant, pair programming is already a productivity technique. That's my understanding or pair programming not just two people sitting together. Two people may code together for learning or mentoring purposes, however we pair for productivity reasons - productivity in the long term.
Like any other XP practice, this one aims to promote the values:
When I pair I get immediate feedback about my design and ideas. The communication is direct and the conversation provides us with simplicity. Good pairs respect each other and have the courage to split when necessary.

In my experience, it takes quite a lot of time to become a productive pair because one needs to learn how the other think. You need to know when the other person is focused not to break her flow. The navigator should never perform the role of the IDE, we obviously don't interrupt to say... "you missed a bracket in there" as the IDE is already highlighting the mistake. We wait until the driver is not typing to ask questions, propose changes or take turns. Nevertheless waiting for the silence in order to start up a discussion is not enough. When I am the driver, I need my pair to realise that sometimes I need silence to think, specially when my flow is appropriate. The fact that I am not typing does not mean I am ready to talk about other levels of abstraction. As the driver, when this happens I ask the navigator for a few seconds of patience and trust. Flow is one of the most important principles when it comes to TDD and Pair Programming to me. If the flow is interrupted continuously, pairing is frustrating. As a navigator part of my mission is to discover when the driver is ready to listen to me. Although a healthy pair is talkative, silence is necessary. The amount of silence depends on the context. If the navigator is a junior (means that he lacks some knowledge - domain or technical) then as a driver I need more time to demonstrate my points. I need to conquer little milestones with code to later explain the underlying rationale with words. In this case, talking about written code that works, feels easier to me.
I've learned recently that sometimes I just need to ask the navigator to be quite and write down notes that we can discuss some minutes later. Although I used to be open to discussion at anytime, I've learned to prioritize flow. If the navigator is a senior then his comments will be practical and direct and so continuous discussion feels more natural.

The silent moments I am talking about last between 30 seconds and 3 minutes. Being quite for more than 5 minutes might be a sign that the pair is not working well. So yes, there is a conversation which is not the same as thinking out loud. My recommendation is that the navigator always has some paper notes to avoid thinking out loud half baked ideas. Discussing half baked ideas is OK as long as the driver is not typing. If I am typing I can't listen to my pair.

Pairing is also about adding the right amount of pressure to the other. The driver should engage the navigator to avoid the "back-seat" driver syndrome. Taking turns help. Alternate often when the pair is well-balanced. Consider taking longer turns when there is a junior. Be careful, if the pressure trespass a certain threshold part of the intellectual capacity is cancelled. We can't think properly under high pressure.

There are different kinds of interruptions from the point of view of the abstraction level. Low level abstraction comments are easier to handle than high level ones. For instance, say the driver has stopped typing and she is observing the code she's just written, the navigator could say.... "that method should be private, rather public". The level of abstraction of that comment is very likely compatible with the current thoughts of the driver, she can easily accept the change and still focus on the TO-DO list. However, something like "how would you implement that in Clojure" might kill the flow. That comment is OK once the driver is open to discuss. Having a TO-DO list or some kind of little roadmap that is created at the beginning of the pairing session is important to focus on the right level of abstraction.

There is a lot to write on pair programming, this post contains just a few ideas related to my recent experiences. I like this funny list of ways to hate pair programming - the challenge lies in getting to know your pair enough to notice when you are pairing badly.

 

 

Polymorphic Equality

The default generation of Equality members provided by Resharper let you choose three different implementations when overriding the "Equals" method in a class (Alt+Insert -> Equality Members):

The default choice is "Exactly the same type as 'this'" which IS NOT polymorphic. I mean, subtypes of that class will be considered not equal regardless of the values:

equalityGeneration
  1. public override bool Equals(object obj){
  2. if (ReferenceEquals(null, obj)){
  3. return false;
  4. }
  5. if (ReferenceEquals(this, obj)){
  6. return true;
  7. }
  8. if (obj.GetType() != this.GetType()){
  9. return false;
  10. }
  11. return Equals((Base) obj);
  12. }

On line 8 it compares the types which in the case of subtypes will be different thus returning false.
I didn't pay attention to this detail today and for some reason assumed that the comparison was going to work for subtypes. Lesson learned: always pay attention to generated code!

This is the generated code to consider subtypes equal:

  1. public override bool Equals(object obj){
  2. if (ReferenceEquals(null, obj)){
  3. return false;
  4. }
  5. if (ReferenceEquals(this, obj)){
  6. return true;
  7. }
  8. var other = obj as Base;
  9. return other != null && Equals(other);
  10. }

And this is yet another implementation that works:

  1. public override bool Equals(object obj){
  2. if (ReferenceEquals(null, obj)){
  3. return false;
  4. }
  5. if (ReferenceEquals(this, obj)){
  6. return true;
  7. }
  8. if (!(obj is Base){
  9. return false;
  10. }
  11. return Equals(other);
  12. }

The other lesson learned is that overriding the Equals method in the child class when the base class already overrides it, increases the complexity too much. The code is hard to follow and surprising. It increases the coupling between the child class and the parent.
Avoid overriding the equality members in class hierarchies if you can.

What is a ViewModel?

A ViewModel is one of the three parts that comprises the MVVM (Model View View-Model). This pattern is a variation of the Presentation Model (M. Fowler). In the Presentation Model, as opposed to Passive View, the "controller" doesn't hold any reference to the view - and it isn't called "controller" but "Presentation Model". The View is the one which references the Presentation Model. The Presentation Model communicates changes to the View through events and data-binding. The View handles GUI events (user interaction) and may invoke methods on the Presentation Model.

In 2005, John Gossman from Microsoft introduced the MVVM pattern which has been evolving since then. In this post Josh Smith explains the pattern as it's commonly used today with an example. According to this post, a ViewModel is an object which wraps a model (CustomerViewModel contains a Customer model inside). However the another ViewModel is the MainWindowsViewModel, an abstract representation of the MainWindow. So there you go, the same term is used for two different things. So what is a ViewModel?

In this other example by Jeremy Likness, there is a class called Contact which he says is a Model, a domain model. I bet that to some people Contact is rather a ViewModel - specially given its implementation of INotifyPropertyChanged.  This is getting more and more confusing!

In our team, a ViewModel is the class handling all the logic related to the GUI. It acts as an Application Service, the entry point to the hexagon. I believe that in his book, Vaughn Vernon discourages the reader from using this kind of "controller" as an application service. But we haven't encounter any good reason not to use it as such. In fact, I find the definition of application service quite contradictory in that book. We never expose domain models directly to the GUI. We may wrap domain models into other objects which in turn are bounded to the GUI (data-binding) and implement interfaces like INotifyPropertyChanged. Although more often than not, our domain models are not even there. These objects are definitely a kind of "view" of the model, I was tempted to call them "ModelView". I understand they may be called ViewModels, it's reasonable. In some articles thew ViewModel is more model-ish than view-ish. Nonetheless to avoid the dilemma of calling these objects ViewModels, we decided not to add the suffix *ViewModel to them. We simply keep them under the *.ViewModel namespace but they are just objects - a Vehicle, a Customer...
What we definitely know is that they are not domain models. They are anemic models to support a particular view of the application. They should not hold references to other services. The application service (what we call ViewModel) holds the references to these data bounded objects in order to get the information from the user.

It's important is to remember the Presentation Model. It does not make calls to the view, it should not have references to any view component. If the GUI logic requires to pop up a confirmation dialog, the Presentation Model (ViewModel) should not make a direct call to some kind of "Dialog", it should rather trigger an event that the View can listen to show up the dialog.

What do you think? I appreciate your comments and thoughts 😉

 

 

 

 

DTO vs Domain Models – Part II

As we learn more about the business and the domain we are taking the time to improve the design of the software. The first handful of features have been deployed into production, now it's a good time to measure, gather more feedback and redesign. In Par I, we exposed some of the difficulties we were facing when modeling. Changes we are making:

  • We are changing the repositories to work with aggregates (entities). This is, rich domain models rather than plain anemic models. The repository performs database queries and then pass in the raw results to the aggregate's constructor or to some adapter to build up the model.  Thus the repository returns models to the service layer and receives models.
  • We (the team) are changing our definition of Data Transfer Object. Currently an object is a DTO only if it's used to send and receive data from the GUI (often through data binding) or via HTTP requests. In the case of the GUI, those DTOs may be considered ViewModels. Otherwise they are just anemic models which means they are an opportunity for us to improve the design.
  • Transfer the minimum amount of data for each operation, no more. A single service may work with many different DTOs because each operation requires different data setsFor instance, the OfferService (an application service) has public methods to create and update offers. The OfferDto used to contain all the data required for both operations:
         public void Create(OfferDto offer);
         public void Update(OfferDto offer);
    However only a subset of the data is required for each operation. Now we prefer to exchange a minimal amount of data:
         public void Create(NewOffer offer);
         public void UpdatePrice(OfferId offerId, decimal price);
    public void Update(UpdatedOffer offer);

    This approach help us realize those objects are used just to transfer data, nothing more.

Slowly we are evolving from a data-centric approach to a rich domain model.

 

Today has been a special day. Not because it's my 34th Birthday which I never really celebrate (although I do appreciate all the greetings and warm words from all my friends and family!) but because I've had the pleasure to spend the day working with Carlos Peix for the first time. Carlos is a well-known software craftsman from Argentina. It's his first time in Spain and we are lucky that he chose us to spend two days working with us as part of his journey. It's an exchange, something a journeyman does to learn and share. Among other things we have been mob programming today, refactoring code aiming to come up with a proper domain model. We have been identifying anemic models and data transfer objects trying to turn some of them into domain models. Trying hard to make up a good object oriented design. Things I like from Carlos' suggestions today:

  • Enumerate a list of all the classes we plan to refactor (or classes that are going to be affected) so as to be able to estimate how much time we are going to invest in this task and thus make a better decision on where to stop refactoring.
  • Rather than refactoring every object in depth, apply little changes to all the objects visiting all of them to build a mental map of dependencies and structure. For instance, we decided we wanted to hide setters and create constructors to inject the attributes. Although a single class suffered from other smells, we performed only that change to it and moved to the others until all of them changed. To me it's like exploring the tree breadth-first.
  • Sequence diagrams help understand the complexity of the design. It's funny that this should happen exactly at the same time I am reading Sandy Metz's book on OOP. Carlos hasn't read the book but he recommends the same technique than Sandy Metz. The sequence diagram was an "aha" moment to my colleague Miguel.
  • We commented on the different strategies to expose an object to different bounded contexts, using interfaces and using wrappers. We didn't have much time to dig into it.
  • Repositories retrieve aggregates when possible, that is rich domain models rather than anemic models.

Looking forward to more synergy tomorrow, it's been an exciting day.

And you fellow journeyman, remember that we are open minded and value your visit to our office. If you want to work with us for a few days drop us a line, we look forward to it!

As I am getting older my memory doesn't work as it did some years ago. If want to remember and internalize the important stuff from all the things I study, I just have to blog about them for two reasons:

  • being able to come back to my blog to reread
  • record it better on my mind - forcing my brain to explain what I learn produces a deeper learning experience

I was lucky to participate in a nightly mob programming session with Sandro Mancuso and other fellow craftsmen during Socrates Canaries when I first saw his way of writing acceptance tests. Now with Sandro's Screencasts we have a great material to study and explore. We have to thank Sandro for exposing himself with these code screencasts specially because they are for free and unedited. What happens with screencasts (because I record screencasts myself) is that after a while, perhaps after a bunch of months you change your way of coding, you find little tweaks along the long journey of continuous improvement that may make you feel a bit embarrassed when you review your old videos. Specially for this I appreciate the effort Sandro is putting into the community.

The main pick I take from the recorded kata is what I would call an "evolving acceptance test" and "deferred dependency injection". When I write a test, I don't want to change it later. In TDD the production code evolves with each test however my tests should not change even when I refactor the code. And this is also true for the acceptance tests when it comes to the "act" and "assert" parts but not necessarily to the "arrange". I have learned that I can postpone the decision of where and how are my dependencies going to be connected. On Outside-in TDD #1, Sandro knows there is a Console object and spies on it but the object is not injected yet into the Account object - by the way, the kata is better understood if the Account was was named AccountService. He defers the decision on how to wire up dependencies. To make it more intention revealing what I am doing now is to get the service under test from a factory:

  1. AccountService service = Factory.AccountService();

Now all I have to do is to change the factory method whenever I am done with the low level unit tests. But I don't have to have the object graph on my head at the time I am writing that very first test. Nice one.

Now when it comes to the unit tests, my outside-in style used to be very similar to Sandro's but in the last couple of years it has changed slightly. I try to mock only the boundaries of the system. Only those things I don't own. As an example, on the Outside-in TDD #2, at about 2mins:49secons he creates a test to spy on the StatementPrinter. That test turns out to be exactly like the production code which makes it pass. It is strongly coupled to the implementation. I would rather use a Console spy to test that properly formatted statements are sent to the console, thus hiding the intermediate collaboration step from my test.
But I would do so probably using Sandro's technique of deferred dependency injection - I don't know whether I really want to inject the Console into the Account. So the production code will likely employ the StatementPrinter but my test wouldn't know about it. To shorten the feedback loop I often fake the implementation (yes, "return true"), that gets me an idea of the complexity of the problem at hand. Then I turn to read and triangulate to get to green with the minimum effort. Eventually I would end up with the StamentPrinter as I refactor.

Essentially I like my tests to know only what is strictly needed from the implementation so that I can refactor often without breaking many tests.

What about you? What things do you do differently?