Visual Studio Tricks - UML Validation of your Intended Architecture

Now for the third post from the series of Visual Studio Tools I Can't Live Without on using UML diagrams to validate your intended architecture.

Part of what I do when I run a code review is to extend it with a report on design divergence. That is when I look at what the intended application design was and what has actually been implemented.

This takes several long and probing interviews with the application architect or technical lead, asking questions about what they think has been coded. Then I look at the code at a high level, with more attention paid to sections with more complexity.

Sometimes it is pretty spot on. Sometimes it is very very different when we get in to the code.

As mentioned in other posts, I will use tools like dependency graphs to get a quick high level understanding of a code base. Another tool that Visual Studio gives me that I didn't have in the past is UML diagram validation of code.

Visual Studio has a project type called a Modelling Project that allows you to create different kinds of UML diagrams that communicate what your intended application design is or are created from code and show the implemented application design.

Again, there is a lot of documentation on how to create these diagrams. The main thing to know is that there are many different types of diagrams and once you put them in place, they can be used to validate the actual code.

Using these tools, you can reverse engineer a code base quite quickly and take in the high level design visually, which is for me the fastest way to understand an application architecture.

It is also quite revealing in that it can show boundary violations between components that cause future extensibility pain. In one case, we identified calls being made from the view directly to the data access layer, bypassing business logic layers. The architect there didn't realise that some of the less experienced developers didn't know they shouldn't do things like that.

Layer and Class diagrams are my favourites. The ability to drag and drop a file from the Solution Explorer in to the diagram makes them a breeze to create.

Once I have diagrams in place, I communicate to the technical leads how to continue to use and create them for regular checks and even in gated check-ins.

A picture really is worth a thousand words.

Visual Studio Tricks - Dependency Graphs

In the second post of this series of Visual Studio Tools I Can't Live Without are Dependency Graphs.

When I conduct a code review or set up a gated check-in, static code analysis will give a list of all the things that are wrong based on a predetermined set of recommended practices. These are mostly superficial and not 100% indicative of whether a code base is bad or terrible or should be burnt to the ground.

Usually, people will look at the number of of errors and warnings found by static analysis to draw conclusions. These can often be the same issue over and over due to things like copy and pasted code, generated code or agreed practices that counter recommended practices.

In any code review I carry out, there is more than just a list of errors. There is an understanding of where those errors sit in the the scheme of things, how serious they are and if they are an indication of worse things to come.

To draw theses kinds of damning or freeing conclusions, an engineer must understand the code base. We have only days to get to this point so we draw on everything we can to help us with understanding what we are judging.

Years of experience will help.
A walk-through with the technical lead will help.
And a picture that speaks a thousand words will certainly help.

With Visual Studio 2012 (VS2012), I have embraced and celebrated the idea of Dependency Graphs along with Analyzers.

There are a lot of instructive posts about how you go about this. There is no need for me to walk you through it.

What I do want to do is make you aware that there is a way to look at the complexity in code in a visual way. You can find and explore circular references, unreferenced nodes and hubs which are highly referenced nodes.

One place this is valuable is in code reviews of pending change sets. VS2012 can filter to just pending changes. This allows a technical lead to ensure that unnecessary complexity is not introduced with bug fixes or added features.

If you need to understand how your code is connected then use this tool. You may even become dependent.

Visual Studio Tricks - Code Clone Detection

It seems that the tools I take for granted are not used by all. This is the first in a series of posts where I will be sharing some of my essential Visual Studio tools that every .NET developer should be aware of. If you already are then avoid me stating the obvious and go read something else.

Call me Code Review Girl and hand me a cape. In my role, it is common for me to travel the depth and breadth of Asia, Australia and New Zealand to conduct a code review and design divergence checks on very large government and commercial code bases.

Microsoft has internal tools that let us do that with great ease. This is always where we start. However, we often go further with remediation plans and sit with developers to show them the kind of things we found in their code that need improving. We don't just show them how to fix it but explain why these issues are issues and how they can be tracked down. In my case, I use pair programming to start. Teach a dev to fish and all that.

When I pair program with a developer, I will never let them copy and paste code. They can either type the whole thing from scratch or they can write a method and call it in both places. Copy and pasting code is an anti-pattern that will result in bloated code bases and often carried errors.

Now, that is all well and good when you are writing new code with another developer but for the times when you aren't watching and enforcing that rigour or for past crimes, Visual Studio 2012 gives you Code Clone Detection.

I won't go in to too much detail repeating what the link above explains but I will give you a quick summary of what you get and how to use it.

Code Clone Detection looks at code statements of 10 or more lines that appear in methods and properties across entire projects or solutions. It works on code with up to 40% of its tokens changed and with statements that have been rearranged.

There are two ways to use it:

1. Highlight a specific piece of code, right-click and choose to Find Matching Clones in Solution; and find that specific code repeated; or
2. Use the Analyze menu to Analyze Solution for Code Clones and find all occurrences of repeated code.

There are ways to exclude certain files like generated code and you will want to do that with large generated code bases.

I find this one of the most useful tools when looking at how to attack a large code base that needs a refactoring machete. This is a tech lead's best friend. Or at least one of them.

Let the clone wars begin.