My team structures projects by breaking things up into small isolated components that can be reasoned about independently.
We'll often do it at the level of namespaces, where a namespace will describe a particular workflow or data transformation, and namespaces tend to be 500 lines or less. It's a similar idea to microservice architecture without the overhead of having to actually split the application up into separate processes.
We'll also often pull out code into libraries when we notice it being generally useful outside the original use case.
I find that there are a lot of benefits to structuring your code using small components instead of monolithically as tt's easier to reason about and reuse. Any large application can, and in my opinion, should be broken down into small parts that are then composed.
```
breaking things up into small isolated components that can be reasoned about independently
```
- This is insufficient for the same reasons unit tests are not enough and you also need integration tests. The moment you cross namespace boundaries, you will end up not setting keys /entries in maps , missing logic etc and end up needing something like Spec/Schema....
> We'll often do it at the level of namespaces, where a namespace will describe a particular workflow or data transformation, and namespaces tend to be 500 lines or less
Are there any open source Clojure projects that are structured this way? I'd like to see a working example.
My experience with dynamic types comes from developing in Python. The projects I've seen were pretty healthy until a large enough part of the original team went away. Once enough people had to figure out their way by experimenting, the projects got messy.
I'm not saying this doesn't happen in Java or Go but the static typing enables easier code exploration. That makes code bases more readable to newcomers.
yogthos|4 years ago
We'll often do it at the level of namespaces, where a namespace will describe a particular workflow or data transformation, and namespaces tend to be 500 lines or less. It's a similar idea to microservice architecture without the overhead of having to actually split the application up into separate processes.
We'll also often pull out code into libraries when we notice it being generally useful outside the original use case.
I find that there are a lot of benefits to structuring your code using small components instead of monolithically as tt's easier to reason about and reuse. Any large application can, and in my opinion, should be broken down into small parts that are then composed.
draklor40|4 years ago
avtar|4 years ago
Are there any open source Clojure projects that are structured this way? I'd like to see a working example.
praptak|4 years ago
I'm not saying this doesn't happen in Java or Go but the static typing enables easier code exploration. That makes code bases more readable to newcomers.
neutronicus|4 years ago
A sort of enforced distinction between (typed) interface and implementation.
In practice I always wound up needing to read code of functions to see what types (or keyword argument!) they expected.
kaliszad|4 years ago