NDepend

Improve your .NET code quality with NDepend

An Introduction to Clean Architecture

An Introduction To Clean Architecture

It seems to me that the topic of software architecture has attracted a lot of interest in the last few years. And among many different flavors and styles of software architecture, there’s one that attracts even more interest than the others. I’m talking about the clean architecture, proposed and evangelized by Robert C. Martin, a.k.a. Uncle Bob. (And for the rest of this post, it’s simply referred to as “clean architecture.”)

By employing clean architecture, you can design applications with very low coupling and independent of technical implementation details, such as databases and frameworks. That way, the application becomes easy to maintain and flexible to change. It also becomes intrinsically testable.

We’ll start today’s post not by explaining what clean architecture is right away. We’ll first dive into the problems that high coupling can cause in software projects. Then we’ll proceed to see the more mainstream solution to these problems.

Finally, we’ll explain the flaws with this solution, showing why and how clean architecture can be the piece of the puzzle that was missing for your application to achieve its full potential.

“Desperation” of Concerns

If you have at least a couple years of software development experience under your belt, then I can almost guarantee you’ve heard the term “separation of concerns.” It’s a principle that shows up quite often when talking about software architecture.

One of its incarnations is in the form of advice: “Separate presentation from business logic.” It’s very sound advice and I agree with it wholeheartedly, but the problem is that it’s not so easy or clear how to put it into practice, especially for beginners.

In practice, what ends up happening is that logic business frequently leaks to the application’s UI. And the same can go the other way around: it’s not so rare to find business logic code concerning itself with UI concepts, such as colors, markup languages, font sizes, and what have you.

And things can get even worse when you add data access to the mix. How does one free oneself from this mess?

Continue reading An Introduction To Clean Architecture

Unit Tests Correlate With Desirable Codebase Properties

Unit Tests Correlate With Desirable Codebase Properties

Today, I give you the third post in a series about how unit tests affect codebases.

The first one wound up getting a lot of attention, which was fun.  In it, I presented some analysis I’d done of about 100 codebases.  I had formed hypotheses about how I thought unit tests would affect codebases, and then I tested those hypotheses.

In the second post, I incorporated a lot of the feedback that I had requested in the first post.  Specifically, I partnered with someone to do more rigorous statistical analysis on the raw data that I’d found.  The result was much more clarity about not only the correlations among code properties but also how much confidence we could have in those relationships.  Some had strong relationships while others were likely spurious.

In this post, though, I’m incorporating the single biggest piece of feedback.  I’m analyzing more codebases.

Analysis of 500 (ish) C# Codebases

Performing static analysis on and recording information about 500 codebases isn’t especially easy.  To facilitate this, I’ve done significant work automating ingestion of codebases:

  • Enabling autonomous batch operation
  • Logging which codebases fail and why
  • Building in redundancy against accidentally analyzing the same codebase twice.
  • Executing not just builds but also NuGet package restores and other build steps.

That’s been a big help, but there’s still the matter of finding these codebases.  To do that, I mined a handful of “awesome codebase” lists, like this one.  I pointed the analysis tool at something like 750 codebases, and it naturally filters out any that don’t compile or otherwise have trouble in the automated process.

This left me with 503 valid codebases.  That number came down to 495 once adjusted for codebases that, for whatever reason, didn’t have any (non-third party) methods or types or that were otherwise somehow trivial.

So the results here are the results of using NDepend for static analysis on 495 C# codebases.

Continue reading Unit Tests Correlate With Desirable Codebase Properties

Value Objects A Tool for Self-Documented Code and Fewer Errors-01

Value Objects: A Tool for Self-Documented Code and Fewer Errors

Have you ever heard of value objects? I bet you have. Even though they’re talked about a lot less than I’d like, they’re still talked about enough that many developers have at least some passing familiarity with the term.

“Passing familiarity” isn’t good enough, though. So that’s what we’re fixing with this post. Today you’re going to learn what value objects are and how you, as a C# developer, can harness their power to make your code clearer, self-documenting, and less error-prone.

What Are Value Objects?

Value objects are one of the building blocks of domain-driven design, as proposed by Eric Evans on his seminal book Domain-Driven Design: Tackling Complexity in the Heart of Software.

Simply put, a value object is an object that represents a value. And I’m aware that sounds excruciatingly obvious and even boring when said this way. So, what’s all the fuss about it?

Continue reading Value Objects: A Tool for Self-Documented Code and Fewer Errors

Delegation as a developer Building the Next You

Delegation As a Developer: Building the Next You

“I love me some me!”  

Yes, there’s more than just an ounce of truth in that statement said by the great NFL receiver Terrell Owens.  Terrell loved some Terrell. In fact, if you knew one thing about the man, it’s that he loved himself. Most of us can hide it a little bit better than Terrell, but we’ve all been guilty of this sentiment at one time or another. We suffer from pride and do our best to counteract it with humility.  I’ll admit it—as a software developer, after I write a solid, beautiful piece of code, my pride gets a first-class ride on the ego train!

Why start an article about delegation with an eccentric statement about ego?  The truth is we’re all good at what we do.  We spend time honing our craft, studying our industry, and trying to better ourselves.  Eventually, through experience, we’re able to understand and execute on things that less senior developers just can’t.  Our peers and managers recognize this, so we begin the journey to the role of leader.  And that leadership role doesn’t just entail learning all of the new frameworks and extensions. It also means learning a new set of skills.  One of those skills is delegation.

The Quandary of Leadership

When I was first recognized as a leader on my team, the recognition was extremely rewarding.  I had worked hard as a developer on this team and naturally stepped into some very minor leadership roles along the way.  I was honored to be selected as the team lead, and soon the team was coming to me for direction while the boss was looking to me for updates on how the team was performing.  

Rather quickly, I found myself thrust into a lonely middle ground. Management expected me to keep my team on task, and I was also trying to meet my standard deliverables.  It was obvious that keeping the team running and efficient required some new skills, and these skills weren’t the kind of things I could obtain by entering commands on my keyboard and getting results.  

These were skills that required—gulp—talking to people and finding out what makes them tick. Oh, and guess what? These skills had no tangible output. There was no rewarding pull request with a peer review after finding out that Jack needs a little more help with CSS and could use some training there.  There was no successful build notification after discovering that Diane had some issues going on at home and it was starting to impact her work output.  While I spent time building relationships with my team members, guess what I was NOT doing?  Producing!

All my career to this point was spent producing. Talking and relationships were a side gig that never got much attention, but they unknowingly got me much further along in my career than I like to admit.  I always liked to think that I would be promoted on technical merit, but it seems that managers are always looking for the next manager, and the technical merit is just expected.  

This transition from producer to leader presented me with a new skill set to learn and start putting into practice.  

Continue reading Delegation As a Developer: Building the Next You

Following the Software Architecture Career Path

Following the Software Architecture Career Path

I can recall a certain day in my career with remarkable clarity.  I say remarkable because this happened well over a decade ago, when I was a relatively fresh-faced software engineer.  My manager had called me in for a chat — quarterly review or some such. He said something that stopped me in my tracks.

“Do you want to follow the technical track or the management track in your career?”

Yikes!  I remember panicking.  On an otherwise unremarkable morning, I had unexpectedly come to a crossroads in my career.  Did I want the organizational clout and higher paychecks of management?  Or would I stick with the technical stuff that I so loved?

Of course, this turned out to be a comical overreaction on my part.  My answer didn’t, in any way, bind me for life.  And the whole thing was something of a false dichotomy anyway.  But it did get me thinking about what I would later regard as the software architecture career path.

The Software Architecture Career Path

I certainly wasn’t alone in my confusion over what becomes of programmers as they advance in their careers.  Some continue programming indefinitely, while others, eagerly or reluctantly, become managers and climb the corporate ladder.  But the software architecture career path splits the difference in a confusing variety of ways.

I challenge you to find a job title with as much variance as “software architect.”  The title itself has many different flavors:

  • Software architect
  • Application architect
  • Technical architect
  • Solutions architect
  • Enterprise architect

You get the idea.  But beyond the title variance, you also see wide diversity in responsibilities.  Some architects are literally just programmers with developmental job titles.  Others are highly technical, mentoring developers and approving of solutions.   Still others are more like project managers or business analysts.  It really varies.

And in this variance lies opportunity.  You can take the opportunity to find a role that suits you well in terms of responsibilities while also advancing your career.

For the rest of this post, I’m going to talk about how to take advantage of this opportunity.  What skills do you need, and how do you find success?  Bear in mind, I’m also going to describe the different flavors of architects in somewhat broad strokes.  The industry doesn’t have a great consensus on what each of these roles really means, so I’m basing this on my own experience.  Whatever you call the different flavors of architect is less important than what they do in their roles and whether the role might suit you.

Continue reading Following the Software Architecture Career Path