Image for post
Image for post

Code duplication is by far one of the worst anti-patterns in software engineering, eventually leading to buggy and unmaintainable systems.

The fundamental software engineering principle “Don´t Repeat Yourself” was first coined by Andy Hunt and Dave Thomas in their book, “The Pragmatic Programmer”, where they state the following:

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”[1]

The DRY principle goes beyond mere code duplication, and includes all aspects of a system, such as database models, build systems, documentation etc., although code duplication is a fundamental part of it.

The first code smell described in Martin Fowler´s book “Refactoring” is code duplication, and along with support from Kent Beck they claim the…


Image for post
Image for post

Swagger is a great way of dynamically documenting web APIs. However, I have seen a great share of broken Swagger set ups, such as the entire documentation failing to generate due to an invalid attribute annotation, or a public controller method which has not been bootstrapped to an HTTP method.

On top of this, it is easy to forget to update the static Swagger configuration, such as the version, title, description and XML documentation file. …


Image for post
Image for post

Swagger is a great way of dynamically documenting web APIs, but as the APIs evolve as new versions it is often cumbersome and easy to forget to update the Swagger documentation accordingly.

However, there are ways to automate the general information and versioning of the Swagger documentation. All components should have some sort of project file that holds the project’s meta data, such as the current version number, and the information stored here can be extracted programmatically and be used in your Swagger documentation. …


Image for post
Image for post

What if I told you that you there was a way of testing the entire business logic in your web Controller “out-of-the-box”, without having to interact with any of your dependent integrations such as databases or dependent APIs, and still being able to test all the integrated aspects of of your ASP.NET Core component — would you believe me? Well, only if you know about the WebApplicationFactory.

Far too often developers tend to test their Controllers by operating on the classes directly, neglecting the entire aspects of how the Controllers are integrated with the ASP.NET Core run time — this leads to one of the most important part of the component being left untested. The next best thing one might do in this scenario is to create a test server from the test-project manually, and creating a new instance of this for each test, which provides the possibility of testing some parts of the integration. However, this solution is not flexible for testing any scenario in your business logic, as it is not possible to mock or stub your dependent integrations in the code. …


Image for post
Image for post

Robert C. Martin argues in his book “Clean Code” (2009, page 133) that writing clean test-code is perhaps even more important than writing clean production-code, “because tests preserve and enhance the flexibility, maintainability, and reusability of the production code”. I very much agree with him. Even when assuming that all the business logic in the production code are covered by automated tests, the code will be hard to extend or maintain if the test-code is poorly written.

Test-code with code-duplication, lack of readability, non-intuitive naming conventions, or lack of formatting, to name a few, will lead to fear of maintaining or extending the production code, difficulties adapting tests to new requirements, and may in worst case even lead to the discarding of existing tests and writing new ones. …


Image for post
Image for post

Integration tests often require you to set up several components that interact with each other, such as running a program and testing various output from it. The work is often time consuming and requires effort — so much that, in my experience, many developers tend to skip or neglect them altogether. In this blog post, we will have a look at the concept of running easy-to-set-up self-contained integration tests, with a code-example in .NET Core / C#.

Why and how to do integration testing?

In my opinion, the most important aspect when it comes to testing your application is to have tests verifying the output of the highest level of your program, meaning the “entry point” where the code starts executing. This can be so many different things, for instance HTTP entry points on a web API controller, or a “Main”-method in your entry point program class. Smaller units that the highest level code is assembled from can be replaced during the development cycle, meaning that simple unit-tests will only get you “that far” in testing the real business logic of your application. …


Image for post
Image for post

SOAP (Simple Object Access Protocol) is a messaging protocol specification for exchanging structured information in the implementation of web services, by using the XML Information Set as its message format (source: https://en.wikipedia.org/wiki/SOAP). The messages can go through a variety of application layer protocols, for instance HTTP(s).

This blog post will have a look at how we can start of with a WSDL (Web Services Description Language) file, generate C# code from it by importing it into our .NET …


Image for post
Image for post

There are a number of scenarios where data values apply for a given month in a year, rather than a given date or time. For example, this could be the average outside temperature or the number of sales in a given month — the examples are countless. For these scenarios, it does not make sense to save the data values together with a date or time, or a combination of the two, as it is misleading to what the values represent.

The most intuitive way to persist such data values would arguably be to introduce one column for the year, and one column for the month. Furthermore, it does not make sense in an information system to allow date or time inputs to filter on these values, as this is misleading to which resolution one can filter the values. Even if the date or time had been allowed inputs for such filtering, one would immediately encounter challenges associated with the acquisition of values over a given period of time. …


Image for post
Image for post

My previous blog post argued that one of the most important principles of programming is to avoid code-duplication, and rather reuse existing code for the same functionality — it aimed at providing insights into how anyone could implement their own code-sharing strategy. This blog post will further elaborate on this by showing a concrete example of how you in no time can develop and publish your own Angular NPM packages that can be reused across your different applications.

The first thing we need to do when publishing our own NPM packages, is to make sure we have an NPM registry to push our packages to. If you want to push your package to a public repository, you do not need to set up any authentication. However, if you have a private NPM registry of some sort, you need to follow the authentication setup instructions for that repository, as we will not go into details about that in this post. Either way, you should end up with a .npmrc file in the root folder of your project, containing a list of the registries your application should retrieve packages…


Image for post
Image for post

When finding yourself developing different applications in the same domain you will most likely come across the need for using the same functionality that have already been implemented in another application. However, in a project with many different applications, code repositories, microservices and developers, it is not by any means straight forward to adopt a flexible and efficient code-sharing strategy. In Fortum Oslo Varme (where I operate as tech lead) we have a code-sharing policy of always building reusable code-packages for functionality that are needed by more than one component. This way, it is easy to have control over where the code is located, improve maintainability, reduce errors and the time spent coding, and make it easier to push new features and fixes to all components using the same functionality. We have our own private code registries for our .NET …

About

Magnus Stuhr

Principal Engineer, tech lead, architect, full-stack developer and head of Data Science community @ Computas AS.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store