That's why it's so easy to rush in and agree with everything. In another article, you might have to read 3 points for microservices, and 4 against. But here? Nope.
Factoring? Just something you do with your gut. Know it when ya see it. Grug isn't going to offer up the why or how, because that's something a reader could disagree with.
> note: grug once think big brained but learn hard way
It's basically a lot of K.I.S.S. advice. Of course you should use the best tool for the job, but complexity often sneaks up on you.
> Factoring? Just something you do with your gut. Know it when ya see it. Grug isn't going to offer up the why or how, because that's something a reader could disagree with.
I would dispute this characterization. Grug says it's difficult, and it is, but gives specific advice, to the extent one can:
- grug try not to factor in early part of project and then, at some point, good cut-points emerge from code base
- good cut point has narrow interface with rest of system: small number of functions or abstractions
- grug try watch patiently as cut points emerge from code and slowly refactor
- working demo especially good trick: force big brain make something to actually work to talk about and code to look at that do thing, will help big brain see reality on ground more quickly