Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
The rise of package managers like nuget and npm have made taking on external dependencies into your project easier. Because of this ease, it seems more developers are often adding external dependencies to their project without much thought on the complexity they may be adding. I suggest you can simplify your code by limiting external dependencies.
Frameworks
Some frameworks are going to be the foundation to parts of your application. ASP.NET MVC for example, could be the base framework for your UI. However, it should not be the foundation of your application. You should view it as the HTTP interface to your application. Robert “Uncle Bob” Martin has a talk Architecture: The Lost Years which addresses this point. Developers have been using MVC frameworks as top level architecture which represent the entire application rather than the delivery mechanism.Dependencies
In recent years and the rise of pushing more to the client side, the front-end development space is full of SomeLibrary.js. Take Durandal as an example for developing SPA applications. It is built on top of jQuery, Knockout, RequireJS. In order to developer a SPA app with Durandal, you are at a minimum taking on 4 dependencies. Odds are very good you will be adding more dependencies such as Bootstrap, Breeze, Moment, etc. I’m a fan of Durandal and Rob Eisenberg, which is why I’m really excited to see Aurelia. You may be saying to yourself: “Who cares! These are all popular and mature open source libraries!”. Yes they are, but that doesn’t mean they are bug-free and simple. They may also move at a pace that is quicker than your own release cycle which can lead to you constantly trying to stay current. Any external dependency you rely on is now your code and your problem. How do you explain to a customer or boss of a when you discover a bug that is causing an issue your application? Do you think they care that you didn’t write it? It’s your problem.What Smells?
Automapper is a good example of a popular dependency that can hide a code smell. If you have a lot of DTO’s that you are mapping through different layers, I can see why you would want to use automapper. It would be really annoying to have to write all the simple mapping code from one DTO to another. Hiding smells by using automapper isn’t necessairly the answer. I would rather the question be asked “Why are we mapping X -> Y -> Z? Do we really need 3 DTO’s before getting serialized to the client?”
Limiting your external dependencies can simplify your code. I’m not saying to ditch all your dependencies and to never use anything external. What I’m saying is be very diligent and understand the dependency, how it works and the problem it solves.
Do you really have the problem that dependency solves? If so, why do you have that problem?
Your article on simplicity reminds me of a recent interest I’ve taken to simplify the creation and maintenance of unit tests. What are your oppinions of https://github.com/kbilsted/StatePrinter/blob/master/doc/AutomatingUnitTesting.md here I’ve tried to account for both the problem and a solution.