Consider a simple example to make it more clear.

Imagine we have Contact class:

These are all defined as simple strings, but really are they just strings? Of course not. The Name can consist of First Name and Last Name. Or is an Email just a set of symbols? I know that at least it should contain @ and it is necessarily.

Let’s improve us domain model:

In this classes will be validations during creating and we will eventually have valid models. Consturctor in PersonaName class require FirstName and LastName at the same time. This means that after the creation, it can not have invalid state.

And Contact class respectively:

In this case we have same problem, object of Contact class may be in invalid state. I mean it may have EmailAddress but haven’t Name:

Let’s fix it and create Contact class with constructor which requires PersonalName, EmailAddress and PostalAddress:

But here we have another problem. What if Person have only EmailAdress and haven’t PostalAddress?

If we think about it there we realize that there are three possibilities of valid state of Contact class object:

1. A contact only has an email address
2. A contact only has a postal address
3. A contact has both an email address and a postal address

Let’s write out domain models. For the beginning we will create Contact Info class which state will be corresponding with above cases.

And Contact class:

Let’s try use it:

Let’s add Match method in ContactInfo class:

In the match method, we can write this code, because the state of the contact class is controlled with constructors and it may have only one of the possible states.

Let’s create an auxiliary class, so that each time do not write as many code:

We can have such a class in advance for several types, as is done with delegates Func, Action. 4–6 generic type parameters will be in full for Union class.

Let’s rewrite ContactInfo class:

Here the compiler will ask override for at least one constructor. If we forget to override the rest of the constructors we can’t create object of ContactInfo class with another state. This will protect us from runtime exceptions during Matching.

That’s all. I hope you enjoyed.

Example taken from the site F# for fun and profit.

Imagine a typical situation, we have a method which gives Product by its Id, but if it is not found returns null:

And the one who is going to call this method, should write code like this

We can avoid this null check if we look at this problem from the other side.

Why null is bad idea you can see in many of articles which gives google search results

What if every time when we can’t find something we will return an empty thing, otherwise a thing with one element.

This example will help:

Dear, bring me a glass of cold water, or if the water is hot then empty glass. And I will decide what to do with it.

Helped?

Then an example of the code in here:

Instead of thing we use List<T> and return empty list if we can’t find product or list with one element instead.

And code on the usage side:

Do you see a difference? I don’t.

But we can go further. For this we need another example.

What if after retrieving product, we want find details about it on Amazon?

If we use the usual approach, then code will look like this:

But if we do not violate the agreement that was adopted above, that we always return thing with element, our code might look like this:

.DetailsFromAmazon() also returns List<ProductDetails>

.SelectMany does very simple thing it flattens list of lists (two dimensional list) and returns one flat (one dimensional) list.

// [[1,2],[3,4,5]] - this is List of Lists
new List<List<int>>()
{
    new List<int>() { 1, 2 },
    new List<int>() { 3, 4, 5 }
}
.SelectMany(list => list); // [1, 2, 3, 4, 5] - this is flat list

More about .SelectMany you can see in Jon Skeet’s post

Here the benefits are already noticeable, we avoid one null check. Let’s go further, don’t stop.

We can write one small extension method for IEnumerable<T> with name Match, which takes two functions, look at the code:

And we can change code below on this:

That’s all.

In next article I will show what kind of helpers I use every day on projects at my job.

I hope you enjoyed. :)

Let’s talk about long-term projects that benefit the business and need to be developed and maintained. During this time, entire teams around the project may change, including management. This leads to the fact that the project becomes difficult to manage because knowledge of the project is partially lost or scattered over many people. Things get even worse when looking at the code left by developers who left the team. Even if the team does not change, it’s difficult for us to understand our own code. At best, this will lead to a rewrite of the project from scratch or the Customer deciding not to develop the project at all. It is not effective, looking at how much it costs. This, in turn, will also have an impact on business development. But let's leave the business to customers. To prevent this, we need to find a new approach to project development.

The biggest mistake is that we work together on a project instead of working together through the project. Sounds strange, yes? I will explain what I mean.

This is how the traditional scheme of work looks like. And this at the best-case. The manager describes the customer requirements, wherever (e.g., Excel, Trello, Jira). Developers try to break them into tasks, communicating with each other through communication tools (e.g., Skype, Slack, Mail) and making meetings or phone calls with the manager. After this, developers write code based on accumulated knowledge during all this communication.

Notice, Manager gives Customer Requirements. It is a one-way direction, I mean, he doesn’t receive feedback in the same way, through Jira, Trello. This contributes to the loss of knowledge about the project because no one records meetings and phone conversations. I call this the leak of knowledge.

After one of the developers leaves the project, knowledge is lost because his decision is nowhere written.

At the end of the project, the customer receives the product as a hosted application and only source code, without any documentation and manual, about building and hosting the project or why we take these architectural decisions.

This will be a problem for another team that will continue developing the project and for us.

That’s what I mean by “working together on a project.” Let’s take a look at how the work looks through the project

In this case, we see that all communication between a team occurs through Tasks, which is in the same place as the code. (it can be Jira with Bitbucket where on Task we can attach code branch on which we work or GitHub with own Issues). Notice that the Manager, as a full member of the development team, participates in the division of Customer Requirements into tasks. The whole process of knowledge sharing is through Tasks and comments to him.

No piece of code should be written without a task. No more undescribed problems. All conversations and making decisions now are available to all through Tasks.

This is a good example of how Open Source projects develop.

In this post, I’m not going to disclose why this approach works better or how to organize processes to achieve this work style. All the answers to questions you find in Yegor Bugayenko posts, and the author of the new software development methodology XDSD. Thanks to him for this.

In short, we must keep our accumulated knowledge somewhere in an understandable form and have one source of knowledge about the project. That the project itself had value without us developers, I mean it must be self-describing and self-sufficient.

Probably you have already sighed. I apply this methodology to the project and solve all my problems. It won’t! Even if you implement this approach, one big problem remains. Even if you implement this approach, there remains a big problem.

Communication through Task is only 30–40% of all communication through the project. We, the programmers, mainly communicate through the code we write. I mean that every day we read code which is written by another developer (e.g., Unit Tests, Code Review), who outlined his thoughts about a task through a piece of code.

And if we do not improve the understandability and readability of the code, we will fall into a bottleneck, which depends on the project development velocity.

How to write good code; this is a topic for another article.

Also, if you noticed, I did not mention Agile software development principles and Scrum as one of its realizations. Because there’s a lot written about Agile already and in Scrum, there is something, the lack of which saves us from many problems. I mean meetings. No more Scrum Master needed, which should protect developers from management, and many other side effects. It reminds me of a shepherd protects sheep from wolves :)