Hey guys! I don’t know how much I’ve been sleeping, but just a couple of weeks ago I heard about multi-module architecture in Android projects. What do you think about it? Are you using it in your apps already? Which way is better if you have multiple modules or like “clean structure” (packages: domain data presentation etc.) architecture?

In the advanced membership call yesterday, we touched on an interesting topic: Server Driven UI (or shortly SDUI). Some big companies like Shopify, Airbnb, Booking, etc. have implemented this concept in their apps, and it works very well for them. The main idea is that the BL stays on the backend, and the app retrieves things that it needs to render. Ofcorse, this paradigm is not applicable to each and every type of app, and probably that's why it is not spread too much. I've collected some resources/articles that are explaining the paradigm in more details, and maybe this is something that could work for you: https://shopify.engineering/server-driven-ui-in-shop-app https://engineering.q42.nl/server-driven-ui-at-primephonic/ https://www.judo.app/blog/server-driven-ui# https://medium.com/@tech.rapipay/server-driven-ui-80ae85603747 Hope someone finds this useful.

Hey folks 👋 Here is the recording of the workshop we had last Friday, which was super engaging and collaborative. We spoke about different approaches to: - Modularisation - Structure and Design - Testing and more. Enjoy.

It's not related to physical code/structure One of the biggest issues I've encountered in software development is the misconception that "unit tests" must be tightly coupled to the physical code, such as a class or function. Instead, a unit defines a behavior crucial for users or the business. The structure should be free to change over time. The focus of testing, then, should be on the public API of the unit, ensuring it exhibits the expected observable behavior. Additionally, it is much easier to create a coherent unit of code by starting from the tests and letting the design emerge as a demand of them. TDD helps a lot there. What do you consider a unit to be? How do you approach testing it?

Here is another open-ended question. I like talking about this one a lot. To me, clean code is not the code that follows an architectural pattern coming from a book or article on the Internet, or any common approach people are following in general. To me, clean code is the code that aligns with the 4 elements of simple design: 1. Passes All Tests 2. Reveals Its Intention 3. Has No Behavioural Duplication 4. Has Fewer Elements 1 - The tests are the fastest way to get feedback from the system, whether it works according to the expectations or not. They would tell me exactly what's not working. So the tests play as a guarantee that the system works as intended. 2 - The code should communicate what it stands for, and what it does. Naming (although very hard) is key here. The code needs to be understandable by humans, as we are the ones writing and maintaining it. Computers don't care about readability at all. 3 - The duplication might occur in both physical and logical forms. It applies to structures or concepts related to the business. Two pieces of code may look the same but their nature is completely different, so it does not make sense to merge them. 4 - Partly related to the duplication, and mostly addresses code that is not necessary, but is added to align with another similar part of the code, or an architectural pattern. Think about the UseCase classes that have an `invoke()` function that only forwards a call. Curious about your opinions on clean code and what you consider clean code to be. Share them below