Since I am a software developer, I have been interested in increasing my productivity because there are always more things to learn, experiment with, and accomplish than I could possibly achieve.
Over the last two decades, I have read quite a few books, countless articles, and watched tons of YouTube videos on the subject.
So, when Ali announced his book, it was clear that I would get one.
Everyone is saying: “When you want to learn about the Rust programming language then this is THE book to start with!”
A book about functional design by Uncle Bob?
When I read about a new book by Uncle Bob on X, I was immediately excited because so far I had read almost all of his books and I love functional programming since years. A perfect match!
So I pre-ordered the book already march 2023 and immediately started reading when it finally arrived in january 2024.
If you see such source code, do you immediately think of multi-threading?
What if I would tell you that Task<T> is nothing but a fancy delegate which is not coupled
to threads at all?
Behavior driven development (BDD) and the Gherkin language, first and foremost, are about collaboration and documentation.
The key idea is to specify the behavior of a software system by describing its features using concrete scenarios and examples. By describing the scenarios in the language of the domain and by doing this together with the domain experts, we ensure that each feature is completely covered by its scenarios and that each scenario is specified correctly.
Using this approach ensures that we build the right system.
We write the scenarios using the Gherkin language which is designed to be both, human and machine readable. By parsing the scenarios and automating its steps we turn the specification into executable test cases which verify that the implemented features behave as specified.
Using this approach ensures that we build the system right.
Now, reading raw Gherkin in an IDE is fine when developing and reviewing a particular feature and its scenarios. But when it comes to providing a long term specification, HTML has clear benefits over Gherkin with respect to readability of the scenarios and navigation between features.
For this reason I have added support for generating HTML documentation from Gherkin based feature files to the TickSpec extension TickSpec.Build.
Just recently, I wrote about my BDD approach in one of my projects in this article. I have used this setup now for a while and it actually worked quite well for me but there is one thing which turned out to be quite annoying over time.
As already mentioned in other posts, one of my projects is a web application which aims to bring maximum transparency into backlogs of agile teams. Over time this application grew quite a bit, accumulated quite some features and got used by more than two dozen teams.
Of course, one important strategy to ensure the quality of this application is test automation. I never followed the classic testing pyramid which is based on tons of classic unit tests but rather focused on describing features and scenarios in a kind of a BDD style.
Favoring pragmatic setups, I wrote those tests without any “real” BDD framework which worked quite well for quite some time, but in the recent weeks and months I realized that my setup needs some improvement.
So I decided to invest some time, do some evaluation and start migrating my tests to a “real” BDD framework using feature files written in Gherkin language.
And this is how my journey went so far …
What does software development mean to you? Is it an engineering discipline? It is called “Computer Science”, so is it a science? And what about the “software craftsmanship” movement? Or is it actually art?
MediatR is a popular library in .NET used to decouple components. In Clean Architecture we aim to keep the core of the application as independent as possible from such “details” like third-party libraries and frameworks.
Nevertheless, I have recently read quite some articles and watched some great videos about using MediatR in Clean Architecture based projects.
But doesn’t the usage of MediatR in Clean Architecture break the Dependency Rule?
If you have at least some professional software engineering experience you probably have heard of BDD and probability is high that you just think of Gherkin and GIVEN-WHEN-THEN when you think of BDD. But actually BDD is much, much more as this book illustrates:
Do you have habits you consider as “bad” and you want to get rid of?
Do you have goals you want to achieve but your are not making big progress yet?
If you want better results, then forget about setting goals. Focus on your system instead.
– James Clear, Atomic Habits
The decorator pattern is a powerful tool to apply “aspects” or cross cutting concerns such as logging or caching to a type without breaking the Single Responsibility Principle (SRP).
But sometimes creating and maintaining decorators with bigger interfaces or a bigger number of decorated types becomes a problem. Dynamic proxies can be a solution to this.
When it comes to concurrency my main axiom is: concurrency issues like race-conditions have to be avoided by design because detecting those via testing is pretty hard and actually close to impossible.
So how can we design the collaboration of concurrently executed parts of a software system in a way that classic concurrency issues are avoided?
Every software project of some reasonable size needs some structure to manage complexity and to ensure that it fits into every developers head.
Every structure also implies some rules on which code should go where and which dependencies are allowed, for example
But how to ensure that those rules are followed in the daily business of a software project?
Obviously, you must write code such that the resulting software works as desired. That’s no longer the main problem of software engineering. The challenge is to organize it so that it fits in your brain. Code must be humane. – Mark Seemann, Code that fits in your head
The goal of software design is to create chunks or slices that fit into a human mind. The software keeps growing but the human mind maxes out, so we have to keep chunking and slicing differently if we want to keep making changes. – Kent Beck
You should aim for an architecture of your code base so that regardless of where you look, the code fits in your head. At a high level, there’s seven or fewer things going on. In the low-level code, there’s at most seven tings you have to keep track of. At the intermediary level, this still holds. – Mark Seemann, Code that fits in your head
