Mit der Gründung am 18.05.2020 und der finalen Eintragung ins Handelsregister ist Minicon nun eine eingetragene Genossenschaft (eG).
Die Gründungsmitglieder sind:
- Daniel Ivanovic
- Andrey Mir
- Michael Nikolaus (Vorstand)
Uncle Bob’s Book: Clean Architecture
I’ve re-read this book after 10 Years to challenge my self, how and what I’m doing. This time I read the german edition, which in general I do not recommend when reading it the first time.
First of all I have to say that, after working several years in the IT Industry, the hard thing about creating Software isn’t the Software itself.
There are the processes behind it which makes the Projects fails, and there mainly the missing Analysis and Processes. At least with a clean architecture you can compensate that. But, shit in shit out, will be in the most cases the excuse for the Architects if the Software failed. And, most times, they are right.
As a summary I can point out the most important things:
- SOLID Principals are fundamental, but 80% of developers do not completely understand them.
- Architecture is about building walls between diffent layers.
- If you want to build a good architecture, you need to understand deeply how Code gets coupled and how to uncouple it.
- This Book show you were those walls should be.
Since Uncle Bob is a Storyteller, this Book could be much more light-weighted. But at least, good to read amnd to understand the SOLID Principles. I can not recommend to read through the Part 6, which is about details and everything after it. It’s just timeconsuming and gives you a kind of „Confirmation“ which doesn’t bring you forwad.
Hope this short POST prepared you to read, or not to read the Book. If you check for Uncle Bob’s Youtube video, at least it’s more entertaining and focused.
Coding Principles
I just heard a good Statement about Object-Oriented Programming and Functional Programming. I‘m not against FP but I decided to use the OOP approach. Trying to be best at it.
OOP and FP are tools.
…
It doesn’t matter what programming paradigm you use. The problems presented in most of the articles are about organizing your code.
To me the macrostructure of the application matters a lot more: what are the modules? How do they communicate with each other? What are the common data structures? How are these documented? What are the important business objects?
These are all questions that have nothing to do with the programming paradigm in use, and the programming paradigm doesn’t even solve. A good programmer will learn the paradigm as a matter of knowing one’s tool and will use whichever is appropriate for the given task.
…
So I totally agree with that statement, and if it is hard to understand the paradigms behind the code I write. I‘ll create several Blogposts with Examples and the Pro/Cons behind it.
In general, as you will see, I don‘t Invent something new, at least I try to use the best approach for the Product. And the best thing for a product is, that is easy to maintained and to be evolved.
As a Software Architect, I have my main focused shift to the general concepts and pattern used. Always focused on Stability and Maintainability.
There are many patterns and concepts out there to support a better Maintainability, but many of them are not used by developers and I always have to explain them again and again. So, the following text will shortly explain which I use in my code.
Naming classes and methods
As started years ago with Clean code, we should name our Methods as descriptive as possible right? But, this also has its downsides, so I’ve started the Builders and Manipulators approach. Since the reasoning behind that naming schema is strongly tight of my understanding of how classes should behave. Mainly because, when using an object, I’m not interested in how it services my request. I’m just interested in what I receive, which is much more declarative instead of imperative.
Declarative programming is a programming paradigm … that expresses the logic of a computation without describing its control flow.
Imperative programming is a programming paradigm that uses statements that change a program’s state.
https://codeburst.io/declarative-vs-imperative-programming-a8a7c93d9ad2
So, how I determine the names of classes, methods, and functions?
- A class instance is a representation of the parameters given to the constructor. This representation has a behavior described by its interfaces and its name.
- Functions results are a representation of its parameters a the result and its name.
- Methods describe its changes with its name and parameters.
class Point
{
// Represents a Point in a defined color.
public Point(color)
: this(color, x, y)
...
// Represents a Point in a defined color.
public Point(color, x, y)
...
public String String() => _color;
// Represents a Line with the given end point.
// Since this is scoped to the current Class its clear,
// that this line ist from its starting point.
public Line Line(Point endpoint)
...
// Change its x,y coordinated to the given destination.
// -> In general, I do not recommend to use Modifiers,
// since they are creating mutable objects. But for
// demonstrating this is fine.
public Move(Point destination)
}
This Article is in progress, feed free to give Feedback before it is finished.
Die Zukunft?
- Wird Tesla die Autoindustrie dominieren?
- Wird Apple noch relevant sein?
- Werden Microservices gegen Lambda functions und co verlieren?
- Wird es ein InternetOS geben? Ein Netzwerk welches Daten, Berechnungen automatisch verteilt und man wird noch Streaming Clients benötigen?
- AI Standard sein? Wird AI code schreiben und wir nur noch Definitionen?
- Werden Autos, Drohnen und Lkws Autonom sein?
Ich glaube es ist nur eine Frage der Zeit, schauen wir in zehn Jahren nochmal.