Magical Code

It’s becoming increasingly apparent to me that some of the code I’ve been writing (perhaps even the majority?!) may look “magical” at first glance, or to the uninitiated.

I briefly touched upon this in my last blog post, however, I don’t feel I’ve explored deeply enough into the extent of the problem, or into possible solutions in which I can improve the “maintainability” cost to my code.

This post is written in part to explore this problem further, and to get some feedback into ways to solve this issue.

Causes of Magical Code

Loosely coupled systems can be a pain to track down where the coupling occurs

Although I don’t fully agree with the statement itself, I can certainly appreciate its intent in the context in which it was made. Let’s have a look at some of the factors that I think may have formed the basis in which this opinion was founded.

  • Application of advanced .NET features that many developers are unfamiliar with, including, but not limited to:
    • Lambda syntax
    • Anonymous Types
    • Reflection
    • Delegates
    • ASP.NET MVC
      • Specialized controller factory, Specialized Model Binders, and template helpers (input and display builders)
  • Concoction of OSS tools, including, but not limited to:
    • NHibernate, AutoMapper, StructureMap, MSpec
  • Usage of Design Patterns/techniques that some developers may be unfamiliar with, and perhaps that even more experienced developers may have trouble recognising. Including, but not limited to:
    • MVC
    • Inversion of Control
    • Templated Method, Decorator, Nested Closure, Memento, Specification, Event Sourcing , Command Pattern, etc
  • Certain scenarios where IDE tools (we use ReSharper) suggest classes and methods are not instantiated or are unused, or that the sole usage is the unit tests. In actuality, the classes/methods are used through some kind of reflection or created by and inversion of control container. This causes some confusion when identifying points of coupling, and locating “dead code”.
  • Application of conventions for eliminating repetitive code
  • Context/Specification style unit tests using MSpec syntax

Looking for Feedback

I’ve listed some issues that I am aware of that I think may result in some difficulty in the understanding of my code base. If I get some time soon, I would like to post again with some potential approaches to tackling these issues. In the mean time, have you come across similar problems with your code base, or have felt similar friction when pairing? Have you any items to add to this list of issues? Perhaps you have suggestions on how you’ve talked these issues in the past, or have an idea to add?

Let me know your thoughts!

Advertisements

About craigcav

Craig Cavalier works as a Software Developer for Liquid Frameworks in Houston Tx, developing field ticketing and job management solutions for industrial field service companies.

Posted on December 3, 2009, in Uncategorized. Bookmark the permalink. 2 Comments.

  1. It definitely becomes more difficult, but only because we have to train our senses to be aware of different code smells than before. You have to look for more role/responsibility smells, now that you just have decoupled code.

  2. Craig, here’s a response: http://nomad3k.livejournal.com/11185.html. You may think I’ve sidestepped the specifics of the question though. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: