MagnifierInHand

How to Review for the Open/Closed Principle

Alfredo_Alvarez — Thu, 25 Apr 2013 17:55:37 GMT

Introduction

What is the open/closed principle should be the first
question we ask. It states that an entity in a system should be open for
extension and closed for modification.
In terms of C# what it means to us is that a class should only be
modified if a bug is found on it. The rest of the time when we are doing new
functionality we should create a new class.

For functionality that is related it implies that we inherit
from the original object. In terms of
this post the idea is to detect the conditions in which the code in question is
either breaking this principle or it will affect people trying to follow it on
the future.

Which bring us to the followings which elements do we need to look at to
determine how will affect the people in the future?

How does Open/Closed affect test efforts?

When a project does not follow this principle during
execution it ends up impacting the test surface and the amount of regression
needed.

Let’s consider the following application:

It’s a web service it takes a small piece of xml with two values
and operation that will be done to it brings back a result.

On the first iteration they created it with the
functionality for adding since it was all that was needed.

It looked something similar to this:

Public class MathOperations()

{

Public long
GetOperationResult(string xml)

{

Int result=;

This.Logger.StartOperationLog(parser.operand1, parser.operand2,
parser.symbol);

Var parser = new
OperationParser(xml);

If(parser.symbol ==
”+”)

{

result =
parser.operand1 + parser.operand2;

}

This.Logger.EndOperationLog(parser.operand1, parser.operand2,
parser.symbol);

Return result

}

In the implementation above if you think about adding the other 3 operations
for your second sprint would require to ensure that everything works once again
since changes in the main file might affect the processing of the add
operation. How can we make this class
apply the principle and make it only impact the operation execution on our test?

One possible way to do it’s to write the original class
using a factory therefore adding next operations means that only a new class
gets added into this project and only the new class needs to be tested.

It would look something similar to below.

Public class MathOperations()

{

Public long
GetOperationResult(string xml)

{

Int result=;

This.Logger.StartOperationLog(parser.operand1, parser.operand2,
parser.symbol);

Var parser = new
OperationParser(xml);

result =
OperationFactory.GetInstance(parser).DoOperation();

This.Logger.EndOperationLog(parser.operand1, parser.operand2,
parser.symbol);

Return result

}

It means that after sprint one all the test you did for mathoperations would
still apply and not really need to be executed again.

On the next post I’m going to describe how to find out if
your team actually adheres to this principles and what are things that can tell
you.

Code Review: How to improve your personal technique

Alfredo_Alvarez — Mon, 12 Nov 2012 18:50:00 GMT

Last time here besides saying hello we talked about how to be helpful during a code review at any skill level. We showed the different levels of help that can be provided. On this post I want to describe techniques in order to ascend the piramid and increase the accuracy of your review.

So what can we do to improve on each level.

Readibility, Tracing and Support

To improve on readibility Read Code Complete, Read Clean Code, Read the comment on peers code review to see what they are looking for read only a few code guidelines and look at the points that get argued.
To improve application Tracing and support - Talk with whoever runs your application and see what pain points are directly related to missing traces or ids. Write a checklist on the next code review make a checklist of it.

Reliability and Testability

One possibility is to read Reengineering .NET: Injecting Quality, Testability, and Architecture into Existing Systems.
Make a map of things you would need to disconnect a particular service see if it does.
Review all retry loops and make sure that their behaviour is reasonable.

Performance, Security And Concurrency

On the Performance part reading CLRS and doing the exercises and Programming pearls will help. Imagine how it would perform if the code did things differently and compare feel free to discuss alternatives.
For security participate on the thread model of your application keep it in hand when doing the review to see what are the vectors on this specific code. Follow http://msdn.microsoft.com/en-us/library/ff648189.aspx
Concurrency -> Read about threading model in .net http://msdn.microsoft.com/en-US/library/ms173178(v=VS.80).aspx learn about the sync async model and how it works on the background. Use paper to try and draw small parts that work concurrently and see if they would have problem accessing resources. Compare with the code at hand.

Software Design

A book on design patterns, I would say read emergent design.
Code a few application trying the different patterns to see why are they useful.
Read on Frameworks dependency injection and flow control(MVC, MVVM)

One thing that applies to all levels is participate in a more varied amount of code reviews one suggestion if your work allows is oss projects and http://codereview.stackexchange.com/

Hope this helps for the next post i plan to start writing down real world examples of code review situations and go tru them explaining the reason of why each one is a problem.

New role: new blog

Alfredo_Alvarez — Mon, 15 Oct 2012 00:06:00 GMT

Welcome to Magnifier in Hand, where I will be posting about being an SDET and their interactions with the software process.

You' re probably wondering, who is this guy? What qualifies him to be talking here?

Well, let me take the time to answer both of those questions. Currently, I'm a SDET on the PSIT group in MSIT. Prior to this role, I was a Developer for 4 years at Microsoft. I changed positions about 4 months ago and I'm currently exploring this new field and hoping to share my findings. If you want more information about my previous experience, here is a link to my old blog .

Alright, so let's get things rolling. My team has been implementing the practice full team code review. Therefore this is the first topic that I want to discuss (topics about code review will be discussed from now till the end of March). While a lot of my co-workers have asked me for examples of what to look for in code reviews, I'm going to start with the other most frequently asked question which is the following; How can I be helpful in the code review process if my coding skills are not as good as the developers?

The answer is the following: anyone can be helpful in a code review as long as he or she person has basic proficiency with the language at hand. I have made the following diagram to help assess your skill level and determine how helpful you will be in the process.

On my next blog post I'm going to cover what steps can be taken to increase your value as a reviewer and move up in this diagram.