> Use mostly functions, try to make most of them pure.
This reminds me of:
> Eat food, not too much, mostly plants > > -- Michael Pollan
My new mantra: Write software, not too much, mostly functions.
This reminds me of:
> Eat food, not too much, mostly plants > > -- Michael Pollan
My new mantra: Write software, not too much, mostly functions.
Did you have something else in mind here?
The problem is that, as the project continues over time, the sweet spot moves...
If you nest your models/components deep enough that they're forming new abstraction layers, you're nesting them too deep. Backup and use mixin-style stuff instead.
If your business logic or application are nesting pretty much at all, then you haven't succeeded at making good choices in your models/components.
Maybe... Duplication is a code smell, but shit abstraction is a code problem...?
If your product or tool lacks a clear focus and goal, then the code base will reflect that, and will grow and sprawl endlessly.
From personal experience, I worked with a team years ago where product owners wanted a datetime picker or parser for an app we had built. Senior dev on team decided it would be cool if it included some lite NLP. When product owners heard from him how easy it would be to add, they were on board.
He started with a popular existing Python library. But there was a bug with one corner case that was causing problems. So he took the initiative to spend a few extra days on the story to write his own simple NLP date parser.
A couple months later, early on Jan 1st, the new feature wished our ops team Happy New Year by taking down our application.
I happened to open an issue for the library's bug on Github after learning about it from the other dev. The owner there promptly responded to share a simple workaround for the issue. But by that time we already had too much software on our hands.