The framework guy

#architecture #career

I've been working for a couple years as a developer and along these years, i've met all kinds of people that fit in all the seniority spectrum. From the junior that needs supervision in his/her first commit to the dev superstar that build entire systems in a weekend. Don't get me wrong. I'm not the "master of developers". I just think I'm seasoned enough to share some of the insights i've got along my career working with formidable people and foment a productive discussion about the subject of this post: The framework guy.

Disclaimer: I'm not an english native speaker, so, pardon the possible mistakes :P

🧰 Frameworks

Frameworks are greatly important pieces of the software industry. They standardize the way we write code and let us sleep at night knowing that the code we write is supported by a solid foundation (code and community).

More than that, they are production proof and almost aways bug fixes are delivered as soon as the bugs are spotted, what makes them still more valuable. Some of them are in the market for years, and new releases are frequently published, providing us tools to solve our problems in compliance with the latest technological tendencies. They are massivelly adopted.

👩‍💻👨‍💻 The framework guy

"The framework guy" is a developer that was presented to a specific framework in the beginning of the career and learnt how to write framework compliant code.

This developer can deliver a solution fast in the framework he/she is used to. Can solve problems quickly with the framework tools and teach other developers how to work with them.

Due to the comunitary nature of the Internet, there are tons of tutorials out there teaching some ways of how to work with determined tool, what leads the developer to create the habit of searching the web for tutorials and learning recipes to repeat everywhere.

I could use as an example the JQuery library. A lot of developers from my generation begin in the front end world with it and never learnt javascript for real. The same hapens with Lodash, Angular, Laravel, Symfony, Rails... and the list goes and goes...

Please, dont get me as if I was criticising the tools. They're great tools and brought the web to where we are today. The question here is that people are learning how to write code to run on specific tools and not how to use tools to solve problems.

💣 The problem

The facilities offered, however, specially if its an opinionated framework, can constrain the application architecture in their default file/folder structure and bloat our code with tool specific fragments.

As stated by Uncle Bob here:

(...) what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Or do they scream: Rails, or Spring/Hibernate, or ASP?

It's a 2011 statement, and despite the speed of technological evolution in our field, it remains incredibly relevant. Many developers are conditioned to build applications that conform with the framework "file structure" and thus, looking at the top level project structure, is hard to understand what the heck that project does.

And what if the framework be discontinued? What would you do? Would you strive to maintain an ancient 3rd party code or would you rewrite the application and pray to the new framework don't get discontinued too? There MUST be another choice.

⚙️ Software architecture

I am clearly not the mind behind these ideas. Many brilliant people put their brains to try to solve that problem. Along the way, a miriad of solutions were spotted by some of the more experienced heads in our field, leading to some software architectural principles that help us build our applications without the need to bend them to fit the framework we use. The business logic can stay completelly unaware it is running on a framework.

This isolation allows us to write code that is simpler to read, debug, test, mantain and scale.

But the biggest benefit, (for me, at least), is that the code is fully decoupled, meaning that we can change any dependency of our business logic without touching it. So, for instance, if we need to change a data provider to consume an api instead a database, we just need to write the provider implementing an interface, inject it into our consumer and we're ready to go. No refactoring, no stress.

Some of my favorite software architecture styles are:

Ports & Adapters Architecture aka Hexagonal Architecture by Alistair Cockburn (Link to original was broken)
Clean Architecture by Robert C. Martin (Uncle Bob)
Onion Architecture by Jeffrey Palermo

The three architectural styles are very similar to each other, and have as the core principle, the separation of the business logic from the support logic (frameworks, delivery machanisms, persistence mechanism, etc). They allow the object oriented systems to work as they should, and associated with Domain Driven Design, the aplication can express the business logic in a clear and effective way.

Conclusion?

Designing software in a scalable way is similar to craftsmanship. It needs discipline and pratice, but the results became more and more satisfying as you go. In the kernel of this activity, is the ability to project the solution in a way that your tools don't stay in the path when it need to change. Think of a sushiman's job. He cleans his workspace while preparing your meal. There is no cleaning to be done after the dish is ready. Software development can be like that.

I'd like to write a series of posts about software architecture, mainly about software architecture and OOP designing (SOLID, DDD, etc). If you think it would be valuable, just let me know. This is a subject I'm very interested and, for me, writing about it is a great way of learning more.