what is the cons for this style?

[madawei2699]

Hi @Exadra37 Thanks for giving these good guides for Elixir coding, but I'd like to know the cons of this clean style. My thought is that all practices that proclaim an idea need at least to be told what it costs.

[Exadra37]

@madawei2699 Thanks for your question :)

I started to use this approach in my PHP days, maybe 8 years ago. The few objections I see are from developers who love working in big files, saying this approach requires them to have more files open in the editor. Thus, I don't take it as an issue with this approach but rather as a taste preference of the developer. It's worth noting that these developers refused to even try using this approach.

Big files of code are a clear violation of the Single Responsibility Principle and a good entry point for technical debt to creep into a project. Yes, I understand that combining a CRUD resource into a single file without business logic attached to it is a no-brainer, but in production projects, they will become rather complex over time. Some say it will be easy to refactor when it becomes complex, but we all know that doesn't happen often, thus tech debt becomes a growing pain as time goes on.

On the other hand, developers usually love the fact that they don't have to keep scrolling through files with hundreds or even thousands of lines. This approach enforces, by design, writing small files that rarely go above 100 lines of code, depending on the business logic complexity, and adheres to the Single Responsibility Principle, which helps to reduce tech debt.

I honestly don't see any cons worth mentioning in the README, but I may change my mind when I find a real use case where this clean software architecture creates issues in a project.

[madawei2699]

Thanks @Exadra37 In the projects I've experienced, there are currently practicing this style. Still, a problem is that every time a small business change or new feature is made, a large number of files need to be modified. It's easy to have 20-40 file modifications in a single PR, which can easily lead to a difficult PR review. You'll need to wade through multiple files to gather fragmented information to understand the PR's You need to go through multiple documents to collect fragmented information to understand the intention of this PR.

My understanding is that this is clearly problematic, and a small feature shouldn't cause a large number of files to be modified. But I haven't found a good solution yet.

[Exadra37]

Thanks @Exadra37 In the projects I've experienced, there are currently practicing this style.

Good to know that others are using a Clean Software Architecture approach :)

Still, a problem is that every time a small business change or new feature is made, a large number of files need to be modified. It's easy to have 20-40 file modifications in a single PR, which can easily lead to a difficult PR review.

It's hard to give a reply here without seeing the PRs and, more importantly, the architecture of the project.

I usually prefer to review PRs that touch many files, where the code in those files has one single purpose and one single reason to change, rather than going through only one or a few files where several responsibilities are mixed together and more than one reason exists for such a file to be modified.

You'll need to wade through multiple files to gather fragmented information to understand the PR's You need to go through multiple documents to collect fragmented information to understand the intention of this PR.

To me, this sounds more like a separate problem of properly defining the issues and linking them to the PRs, plus having scarce documentation in the code itself. However, I may not be correct due to not being an insider of the project.

My understanding is that this is clearly problematic, and a small feature shouldn't cause a large number of files to be modified. But I haven't found a good solution yet.

Considering a CRUD resource that has 4 possible actions, thus 4 possible reasons to change it, if a new feature requires changes to 20 files, it may be touching 5 different resources. This raises the question of whether the scope of the feature is too big or if the feature really needs to be architected in such a way, or even if the feature couldn't be broken into a series of smaller PR's. However, without seeing the code and architecture, this is just me wondering.