Originally posted on my blog.
The Crappy Projects and The Never Ending To-Do List
Let's settle something right here. Most of my side-projects are never finished crap rotting on GitHub, waiting to be deleted before the next ones. At the same time, I have that ever growing To-Do List where some of the old items are about technologies not even maintained anymore. That, my fellow readers, was the sad record I've made at the end of every year since I've started programming. Obviously, some of the items from the list found a place in the crappy rotten projects and some of those ones succeed to be used a bit by myself. However shipping things is fun, maintaining very less.
Alas the boring parts would always be the same.
Clean Architecture Hammer Savior
Some years back, Android (my day-job programming context) faced a wave of architecture revelations and illuminations. Every other talk and article were about how Clean Architecture could save developer lives and removing spaghetti from the codebase menu. It took me about one article to be drowned and start to cry about how bad I was at programming. However I tried, maybe not for the good reasons (yup sometimes hype is attracting). Coding was even harder than all the articles read and the videos watched. At the time I was almost fully dedicated to the subject (trying to migrate to this in my day-job project and implementing the plenty of examples found on the internet).
It definitely took me years and some aha moments to start to understand the advices some very nice people gave me to use it correctly. The Clean Way™ was not an illumination, it's a slow path where putting all the parts together is taking a certain amount of time. I'm starting to feel almost enough confident to help people with it and talk about the subject. However I won't cover the what and the how to implement here :).
It also gives me a new perspective about what I was expecting when programming. Working with it everyday at my day-job and porting some spaghetti code I wrote before gives me new slow and steady goals.
Safety When Sharing
One of those goals is being able to share my work with confidence even if I don't code very well.
It's impressive to share your own little program on the vast ocean of marvelous projects on the Internet. Most of the time no one notice your errors and even if they do they'll probably help you. Even so, it's frightening.
Clean Architecture is focused on what you want to do with your project. The core part is very abstract and are just definition for your use cases. Sharing it quickly, can help for feedback before even starting to install that Mongo instance (without speaking about the last trending driver) or pushing the actual server on a hosting machine.
It validates your domain. It can also let people talk you about their expectations. It's way easier to write some abstract code (with unit tests because you're someone nice) than trying to implement the whole stack needed for an experiment.
People can also join the project faster and PRs can be related only to pure features, letting other writing the implementations later (or never 😅).
It helps proving your point and let people safely interact with it.
Learning
If all you have is a hammer, everything looks like a nail.
The other thing who struck me recently is how using Clean Architecture can help to have a quick overview about the core structure of a language. It was so obvious that it gave me this blog post idea.
Every language tends to have its own idiomatic way of writing/structuring things. However when creating a new project we tend to go straight to the working code and forget about it until the next one. Putting abstraction first helped me to go a bit deeper, especially when the language is not in a paradigm I use a lot.
My last two examples are Gutenborg (the program transforming my markdown to HTML for this blog) in Rust and stack-bingo in Go. Coming from object oriented programming languages as Java or even Kotlin, it was a bit difficult to implement something with the same structure at the beginning. All the constraints I faced actually helped me a lot to understand if not the ideas behind the language at least the syntax and some of its grammar.
It won't be a silver bullet to be the rockstar developer in the targeted language. It still gives a good constraint to force you to avoid rushing the implementation and missing helpful concepts.
Keeping Your Own Pace
As discussed before, decoupling the codebase helps to work in parallel and let you make evolution without breaking anything. Implementations being a totally different part, if someone is eager to use one of the feature planned on the roadmap but you don't have the time to work on the implementation right away that's okay.
Any new contributor should be able to get it and start develop something.
I think that's also why decoupling stuff is so satisfying. Your core is now your To-Do List with every new feature you would create and all the implementations are branches in the project where anyone can push their marvelous or crappy things.
Conclusion
I'm probably a bit biased here. I like Clean Architecture a lot. I like Domain Driven Design a lot. Maybe I'm just an hostage of practices I've struggled with for so many years.
However it can be a powerful tool to manage new project, learn new language and/or keep sanity when working on the side! It's also tedious to implement but that's part of the fun. I haven't go deeper in the details but I would totally discuss about it. If interested don't hesitate to ping me on Twitter or by email me (at) jobo.to.
A huge warning here.
Sometimes it can be useful to have this kind of overview, it doesn't mean we have to trash project from someone else just for the sake of Clean Architecture. The hammer, the nail etc. Languages and communities have their own philosophy and we should respect them. When contributing please take care about it.
Top comments (0)