August 24, 2017 7 minutes read
Assuming you’ve had at least one job working on one or more C# projects, let me paint a familiar picture for you. I’m talking about your onboarding time with a new group. It’s always an exciting and awkward experience as you feel out teammates and new codebases.
On day one, you arrive. But rarely does anyone expect you to contribute meaningfully on that day. In fact, you probably won’t even contribute meaningfully that first week. Instead, you hear plenty of talk about “learning curves” and how this environment is uniquely challenging. Ironically, every shop I visit as a consultant claims to be uniquely challenging.
Index
C# Projects: the Onboarding Phase
What, then, does onboarding usually look like? I’ll build you a composite picture, based on my travels. I’ll leave out the HR component, with new team member lunches and paperwork; here, we’ll consider only about the technical aspects.
On the first day, you show up and a developer on the team works with you on the basics. You get access to the mundane necessities: network shares, the internal SharePoint, version control, etc. If you get lucky, all of that goes smoothly, and you actually get source code on your machine. But this could also drag out a day or two.
During this time, everyone on the team is pretty busy. You have chunks of time left to your own devices, instructed to study the architecture and design documents and also to look around the codebase. These documents paint impressive architectural pictures of layer cakes, distributed clusters, tiers, and CQRS paradigms. You secretly wonder if they’re accurate. (Spoiler: they aren’t.)
You’d get going on real work sooner, but the architect needs to walk you through the relevant design patterns. This is necessary so you’ll know what goes where without making a serious blunder. Of course, the architect is really busy since all problems bubble up to her. So you wait.
Onboarding Time as Waste
You may wait days, weeks, or months. Oh, you’ll get on the architect’s calendar before months pass. You’ll get the architectural tour, and they might even toss you into fixing defects after a few days.
But still, you wait. You probably wait for months or even years before the team dubs you versed enough in the codebase and architecture to trust you with any and all decisions. And that’s really a shame. It needn’t take that long. In the first place, that steep of a learning curve is a smell that most shops ignore. But in the second place, you can really help yourself speed things up.
Most developers will spend this time assiduously reading documentation. Then, they dive into the code and get confused, since reality usually doesn’t match the documentation. Naturally, they chalk this up to their own faulty understanding. Time crawls by, unproductively.
If they do dive into code, they do it sort of randomly. They start somewhere and idly move in order through the source files in each directory. Looking for what, exactly? They don’t know. Just exploring.
But it doesn’t have to go this way. Even without anyone else’s direction, you can attack a new codebase methodically, dramatically reducing the learning curve. I speak from experience because I assess codebases for a living as a consultant. This requires me to get the feel of foreign codebases very quickly. And there’s no better tool for this than NDepend.
Here’s how you can leverage it. And your new team need not have it; you can do all of this for free, in the span of a trial usage of NDepend.
See the Actual Architecture
Remember earlier, when I claimed that architectural documents are never accurate? I said that because I use NDepend to see the actual architecture. And the actual architecture never matches the spiffy diagrams that teams dream up and document.
Sometimes, in more mature and sophisticated shops, it differs only by a handful of errant dependencies. Other times, it differs so intensely that you’re not sure whether you should laugh or shake your head sadly. But it always differs.
You can get a huge leg up on the learning curve by looking at theactual architecture. Not only does this give you a much more accurate picture, but it also lets you know whether you should even bother trying to learn from the documents.
NDepend does this by showing you a dependency graph at various granularities of code elements. Here’s one showing the relationships among the codebase’s assemblies.
Is This Code Any Good? Metrics and Rules
Any time you come onto a new team, there’s an implication you have much to learn at the feet of established team members. Philosophically, I attribute this to most job interview processes resembling applying for grad school entrance or some such thing. The existing team determines if you’re “good enough” and gives you the stamp of approval, if so.
As a result, you tend to come in naturally assuming that they really know they’re stuff, and they assume you have a lot to learn. So when you find yourself mystified by their approach, you tend to assume that they know some sophisticated techniques that you don’t. But what if you don’t understand because it’s not very good?
It happens. In fact, it happens more than you think. After all, the interview process involves them looking at your code but usually not you looking at theirs.
You can use NDepend to help you get your bearings. NDepend’s issues list can help you get a feel for the quality of the code, and the code metrics can at least set you up to do comparative research. Do they have thousands upon thousands of issues? Lots of critical violations? Lots of gigantic methods and classes?
NDepend gives you what amounts to a thorough third party audit of the code. And you can leverage this to help you get an immediate feel for where the codebase stands — and that feel will be uncolored by the natural power dynamics of your position.
Get a Feel for the Code with Heat Maps
After visualizing the architecture and orienting yourself on the map of code quality, it’s time to start learning in earnest. You can leverage the heat map functionality to fast-track this learning.
The heat map lets you visualize two code metrics simultaneously: one by color and one by size. Here’s an example of what that looks like:
So for instance, you can tell the heat map that you want to see all classes in your codebase, where the size of the box represents the size of the class, and the color of the box represents the number of types that depend on it. As you get good at using NDepend this way, it will start to paint powerful pictures for you.
For example, the view I mentioned can answer an important question at a mere glance:“Does this codebase rely disproportionately on classes that are too big?” On top of that, it also gives you serious insight into which classes you should go learn about first.
And you’ve learned all this from just one heat map. You can create any sort of heat map that you can dream up with the metrics at your disposal. This lets you grok your new codebase in ways that even the grizzled veterans never have.
Querying Code with CQLinq
I’ll conclude by mentioning one final but hugely important NDepend feature: CQLinq. NDepend comes out of the box with a rich set of metrics that you can use. But with CQLinq, you can create your own. And you can do it as easily as writing Linq queries.
This means that as you get to know the codebase, the questions you can ask about it are limited only by your imagination. Do you want to see how many classes implement more than one interface? Or would you like to know what percentage of methods in your code use enums? Maybe you want to see how many classes more than 150 lines long start with the letter C? Hey, whatever you think will give you insight. You can do all of these things and many, many more.
Using NDepend on your new C# projects will give you uncanny early insight, and it will significantly shorten the learning curve. But when you become proficient with the tool, it will give you a window into the codebase that no one else without it has, even using other analysis tools. So don’t spend your early days on a project picking through Visio diagrams and waiting around. Fast track the learning with NDepend.
