Articles with Design

Consideration before building a program

Having looked for Rhino Queues articles and examples, i stopped by this article:Building Distributed Apps with NHibernate and Rhino Service Bus. I read it before but i could not remember anything. I decided to read it again even though it is not much related to the topic i was looking for: Rhino Queues.

It is so good. Especially the way the author thinks before starting an application. He put so many thoughts, consideration. It is called Architect Design; at least i call it. You should read the article.

Then i came up with my coding life, my everyday code. How many times do i really think about those stuffs? And how many developers think about them?

Me? Zero 🙁 poorly admitted.

And now i know it 🙂

Do we need code review?

What is the code review? Simple as its name: Do the review after coding done of a project, feature or just a task. At my company, Catglobe Vietnam, we usually do that, and it is a MUST. PM or TL will do that job.

I was surprised once i asked my friends: How was that going in your company? Got the same answer: No we did not do that stuffs. The first thought came up in my head was that the company is an outsourcing and they do not care much about the quality of code, just passing test is enough to hand over to the client. However, not only that kind of company; company owned the code, call code base, also does the same thing.

How can they build up a good software without reviewing the quality of code, coding style,… ? Being asked that question, they said that: out of resource.

I wonder how many companies really take  care of code review while developing???

Maybe an idea of a code review company ….

Do we need technical design?

Recently, the trend is for XP ( Extreme Programming) and Agile management with Sprint/Scrum, so do we still need technical design for a project?

The purpose of Agile developement is to supply the deliverable product sustainably and XP helps team accomplish the goal. Over the internet, we have found many principles, tips, best practises about coding, how to make a better code. However, noone talks about good technical design. In fact, none exists.

With the agile developement, the project is splitted up into small tasks. Each has acceptance test and customer relation. And most important, the customer is involved and the delivered product satisfy customer and we are ready for the change from them.

Now, let’s assume that we have all stories need to implement in one sprint. And the whole team will discuss how to do it. The question is how to make the technical design for those stories? and does it make sence to make the design for only those parts and the next sprint will continue next parts? I think NO.

Someone will say YES. Then i assume that you have made the technical design for those parts. Then come to the coding. Click here to see XP Practice . In summary it says:

  1. Write unit test and acceptance test, if you follow TDD.
  2. Write code to pass those test
  3. Refactoring code, of course make sure the tests are green.

And how can we refect the refactoring in Technical Design? So still say NO to technical design.

And consider time you spend on that

Someone will say: It keeps the thing we did in case when new comer want to get a preference. Do you really use the technical design to get understanding about the code or you will look directly into the code? if the code wrote 1 year ago and now you come in, what will you do in order to understand it? You only do this if the code has never been refacted.

My conclusion is that: If you are in XP and Agile development, you DO NOT need technical design. Instead of spending time on making the technical design, you should spend time on learning OOP principles, best practices. Then the code will explain itself.

Oobs, Are you throwing technical design away or is it useless? NO. We should consider it as a general documents of the project not the technical thing in detail.

Donot mix up layers in one function

Recently i did some refactoring on the old code. The code works fine as expected. Except that it was hard to test since there were too many dependencies on the implementation.

Here what it look like:

      public static void Accept(Task task)
      {
         task.ActualStartDate = CGDateTime.Now;
         task.Completed = false;

         if (task.ResponsibleResource.ResourceType == ResourceType.Group && task.GetSetting(RuleResource.Rules.Personalize_On_Acceptance))
            task.ResponsibleResource = AccessFactory.CurrentUser;

         task.Save();

         Comment acceptance = new Comment();
         acceptance.CreatedBy = acceptance.ModifiedBy = AccessFactory.CurrentUser;
         acceptance.CreatedDate = acceptance.ModifiedDate = CGDateTime.Now;
         acceptance.Type = CommentType.Acceptance;
         acceptance.Resource = task;

         acceptance.Save();

         UpdateAcceptedChildren(task, acceptance);

         TaskInformer.RegisterForCatTask(task, ApplicationVirtualPath, TaskInformer.Action.Accept);
      }

I am not going to explain more about that implementation and why and how i did the refactoring since it belongs to another topic.

In general, after creating some interface i had this one:

public static void Accept(Task task)
{
// #1 – The implementation
        task.ActualStartDate = CGDateTime.Now;
         task.Completed = false;

         if (task.ResponsibleResource.ResourceType == ResourceType.Group &&
             task.GetSetting(RuleResource.Rules.Personalize_On_Acceptance))
            task.ResponsibleResource = AccessFactory.CurrentUser;

         task.Save();
// #2 – The abstraction
         Comment comment= _commentcreator.CreateAcceptedComment(task);
         _childenupdator.UpdateAcceptedChildren(task, comment);
         _informer.RegisterForCatTask(task,ApplicationVirtualPath, TaskInformer.Action.Accept);

}

 _commentcreator is interface responsible for creating comment based on task

_chidrenupdator is interface responsible for updating its children information

_informer is interface responsible for informing others in the system.

It seems that we’ve alread done or at least at that time i can easily test the function without caring too much on the other parts. However, if you look at the code again, which i have marked with #1 and #2.
WE ARE MIXING THE IMPLEMENTATION AND ABSTRACTION IN ONE FUNCTION.

It should be in the same level.

How to solve the problem? Simply just abstract the implementation part. Here comes with the final code:

public static void Accept(Task task)

{

       _taskinfor.UpdateTaskInfoOnAcceptance(task);

         Comment comment= _commentcreator.CreateAcceptedComment(task);
         _childenupdator.UpdateAcceptedChildren(task, comment);
         _informer.RegisterForCatTask(task,ApplicationVirtualPath, TaskInformer.Action.Accept);

}

The benefit of doing this is obvious.