The Spring Framework is great in how it provides an opinionated way to structure our applications, and because so many people are using it, it’s easy for new developers to quickly familiarise themselves with the codebase.
For those who have written unit tests in Go, the stripped down nature of the language might have produced some inconvenient duplication and seeming messiness in each test. For example, if you have a test for creating a new item, adds a generated identifier and saves in an in-memory data-store, it may look as follows:
One of the things that is most punted about with the Go language is its ease of understanding the code that has been written. The language was built to be as simple as possible, and features that the maintainers deem to be superfluous are left out. Like generics. Some view this as a disadvantage though, as it takes and increased number of key strokes and lines of code to achieve what may have been achieved by a 1 line lambda anonymous function in other languages.
Go as a language is relatively young, compared to older and more ubiquitous languages such as Java, C#, Ruby and Python. The great thing about a new language is that developers aren’t bound to patterns of writing code that may have become entrenched in other languages due to the familiarity of the most common frameworks in those languages. For example, in a simple Java Spring Web application, one has the controllers, the JPA repositories, entities, and the if-else statements in between representing the application logic. The difficulty about a relatively new language is that there isn’t a commonly agreed upon way to do things, making everyone a potential proselyte, tossed back and forth between the waves of various newly evangelized dogma.
2018 has been an interesting year from a personal and professional point of view. It’s like that Charles Dickens line in the opening of A Tale of 2 Cities:
It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to Heaven, we were all going direct the other way.
Over the past little while, I have increasingly found myself having the responsibility in making and advising on technology architectural decisions for various organisations. When working on small and simple use-cases, these decisions are normally about the technology stack of a single application and the structure of that application. But when working within larger enterprises, complexity changes the scope of the decision making from one application to multiple systems interacting with each other.
When creating software applications, separating our code into smaller, simpler units helps in maintaining the codebase, making it easier to understand and thus quicker to make future changes.
In organizing increasingly complex software systems, one normally breaks the complexity down into smaller, more manageable and maintainable units. Within the object-oriented programming paradigm, large classes and methods are refactored into smaller methods and classes to reveal intention to developers, making it easier to understand and make changes. Within a functional paradigm, larger functions can be broken down into smaller functions that ‘do one thing’.
I recently finished reading The Land Is Ours by Tembeka Ngcukaitobi. The book fascinatingly narrates the lives of the first 6 black lawyers in South Africa, all practising in the early 1900s.