Skip to main content

Posts

Showing posts from June, 2015

DRY vs Coupling in Production Code

Duplication in tests can be a good thing. The same can be said for production code as well in some cases. No. I'm not going mad. I probably wouldn't believe this if you showed me this several years ago either. More experience has shown me that loose coupling is often more desirable than removing duplication. In other words, the more duplication you remove, the more coupling you introduce inadvertently.Duplication of logic is bad and will always be the case. I am not debating this. You should only have one logical place for any domain logic. As always follow the DRY principle. However just because two pieces of code look the same, does not mean there is duplication.ExampleA system from my past had two places where an address was required for display and serialization. Billing and Delivery addresses.My gut reaction was to introduce a common address model that could be used for serialization and display. After all this screams of duplication. However a billing address and deliver…

FirstOrDefault in LINQ

Explicit null checking is a code smell in most cases. It should be limited where possible, or pushed to the edge of the system. A common anti pattern I've noticed is the incorrect use of First() in LINQ, which I have used myself on many occasions in this manner.Assuming a collection of items that you wish to query, the incorrect approach is to explicitly check for a null return value and act accordingly.The use of FirstOrDefault() is redundant because no default is actually set. The default value of a reference type would be null. Meaning the explicit null checked is required. We could use First() alone, but this will throw an exception if there are no elements to query against.A better solution is to set the default. As long as our initial query is not operating on a null reference this is safe. Here the explicit null check is gone. We have replaced it with a more functional solution which is after all what LINQ is based upon. While both are equivalent, the second example is much…

Do you really need a Microservice?

Lately there has been two sets of advice around the use of Microservices. Some advise that Microservices should be built after the fact. Others advise the opposite solution. In conjunction there is a third option that deserves more attention. Do you even need a Microservice at all? A recent tweet sparked off the exact thought I have found myself conveying.Creating a Microservice is no easy feat. Despite the limited code or functionality that is involved. There is a whole host of things that need consideration; source control, project setup, databases, project conventions, monitoring, logging, deployment, hosting and security to name a few.The so called monolith or "application" as it was known before is a tried and tested way of structuring applications. One of the big criticisms levelled against monolithic applications is coupling. Having worked with some terribly coupled applications I agree fully with this complaint, but there are steps you can take to prevent this.A whol…

Branch by Abstraction

Feature toggles are great for new features or features that are either enabled or disabled. Branch by Abstraction offers the same benefits as feature toggles but the seam to introduce the change is the abstraction itself. Unlike Feature Toggles, the use of Branch by Abstraction allows a gradual transition to new functionality.Start by duplicating the type or implementing a new version of the abstraction. The work in progress changes can be made safely while the system is using the original implementations. In order to demonstrate the new functionality, rely on automated tests or wire up the new version. Once fully integrated and tested, simply remove the old implementation. The addition or removal of implementations acts as the toggle in this case.To extend the SimpleReceiptWriter a new version is made. This work in progress implementation has no limit on the time to complete. The new implementation will only take effect once configured.Configuration takes the form of composition root…

Feature Toggles

I'm a fan of regular releasing. My background and experience leads me to release as regularly as possible. There are numerous benefits to regular releases; limited risk, slicker release processes and the ability to change as requirements evolve.The problem with this concept is how can you release when features are not functionally complete?SolutionIf there is still work in progress, one solution to allow frequent releases is to use feature toggles. Feature toggles are simple conditional statements that are either enabled or disabled based on some condition.This simple example shows a feature toggle for an "Edit User" feature. If the boolean condition is false, then we only show the "New User" feature and the "Admin" feature. This boolean value will be provided by various means, usually a configuration file. This means at certain points we can change this value in order to demonstrate the "Edit User" functionality. Our demo environment could …