how do folks feel about this approach: <https://ha...

# gradle

[Ben Madore]

how do folks feel about this approach: https://handstandsam.com/2018/02/11/kotlin-buildsrc-for-better-gradle-dependency-management/

i’ve always ensured that there is only a single version of all my dependencies (generally using the io.spring.dependency-management plugin in the root project) and versions stored in gradle.properties

[Czar]

We've been using something like it even before Kotlin. It was not in buildSrc, but in an included groovy gradle script. We have since migrated to buildSrc as part of moving to kotlin-dsl.
Currently it's kind of weird, because we also use spring dependency-management.
I have a plan to look into unifying everything in the future, but I don't have any concrete recipes at the moment. There are many things with higher priority for us currently and time is not a stretchy thing unfortunately 😄

[ribesg]

I’m using a Versions object in buildSrc for versions. I don’t see any value in something like Libs or Deps over just writing the dependencies in the build.gradle.kts file, so I’m not doing that.

[Ben Madore]

sure, for single project i think that totally makes sense, for multi-module projects, i think it’s nice to have IDE support for adding previously-defined dependencies

[ribesg]

I don’t see any value in multi-module projects 😛

[Ben Madore]

architecture enforcement 🙂

[ribesg]

I just have multiple projects

[Ben Madore]

ah, that works too, though, if they’re not meant to be consumed by more than a single app, i don’t like to have to touch multiple repos

[Czar]

I agree with Ben here, we have a large multi-module project and having autocomplete for libs helps a bit. Another thing is that when adding new dependency we sometimes document as to why and what for, and Ctrl+Q is there for us 🙂 As we have several development teams which are geographically separated from each other, that's nice.
@ribesg to each his own, for us multi-module works best 🙂

[Ben Madore]

e.g. my build is modules:

web/
service/
repository/
domain/
common/

[Ben Madore]

having it as multimodule ensures people can’t do crazy shiz like call a service from a domain object

[ribesg]

Well I guess this applies to big companies. For me the rule is just “don’t be stupid”

[Czar]

And now that we have Kotlin and internal, multi-module is even more helpful 🙂

[ribesg]

Sure, I’m missing package. But code review and not hiring bad developers is enough to prevent people from doing crazy things

[Ben Madore]

ya, i wouldn’t use multimodule on a very small 1-2 person team, but when you’ve got a dozen developers coding, having tools to enforce the architecture becomes very important imo

[Czar]

At some point having good developers stops working just on its own. E.g. when the project is 1.5MLOC and you have 5-6 separate teams working on it in parallel, while living in different countries and timezones 🙂

[Ben Madore]

that just means it’s time for microservices 🤣 instead of one free-for-all codebase you could have 30!

[ribesg]

Exactly. I worked at HP before the big split and it was a mess. Now I’m in a not-that-small startup in a 2-person team. I think that for projects with a lot of code multi-module would make sense, but we don’t do that. We try to split things into smaller projects talking to each other. Think micro-services but think more than backend.

[Czar]

Also when working with several juniors on the team, you get tired of fixing simple stuff during code review, which could've been avoided by implementing some restrictions once in the beginning 🙂

[ribesg]

I feel like the answer to junior mistakes is more code review than project structure

[Czar]

I disagree, microservices are not warranted here, monolith is easier to manage, has simpler infrastructure requirements and requires less resources.
The software while complex, is well modularized, has more or less well defined interfaces and is scaleable enough for what we need as a business. We'd have to rise our userbase by several orders of magnitude to warrant additional complexity of microservices.

[Czar]

@ribesg and while I mostly agree, good project structure helps, too 🙂

[ribesg]

Sure, but the knowledge needed to setup a multi-module project... It’s maybe a better solution when you have engineers dedicated to build

[Ben Madore]

ya, in all my years of consulting i’ve just seen too many codebases doing too many weird things that could have been avoided with some architecture enforcement

[Ben Madore]

to me not using modules is about the same as just using one package for everything with all public classes. anything has visibility to anything. no boudnaries

[ribesg]

Yeah no. You can’t just say using and not using packages is the same thing like that 😄 Something being accessible does not mean you should use it. A developer should be aware of the architecture of the project he’s working on, even a junior. And anything used in the wrong place would be easily caught on code review, imports are at the beginning of files

[Czar]

not necessarily, multi-module projects are not that hard with gradle, at least in my 3+ years on this project I have yet to hear a complaint about it 🙂

[ribesg]

I just don’t feel like these kind of easily fixable issues required such hard solution. I guess it really depends on your environment and who you work with

[Czar]

and writing of automated tests can also be avoided by manual testing, but that takes time, as do code reviews, I'd rather setup architecture in a way which makes accessing wrong things from wrong contexts harder, than look for it each time I review a PR

[Czar]

And again, multi-module projects are not hard. It's a basic gradle feature, which is easy to understand and use. It its basic form you need just 10 minutes to read the docs and do it, if you're just reading the setup even reading the docs is not absolutely necessary, most things are just intuitively clear.

[Czar]

Smaller projects can get away without modules, larger ones - not so much. We seem to agree on the first part of this statement. Second part I'll probably just agree to disagree I don't feel that my position could be changed in a slack discussion.