4 ms·
It especially doesn't work in a team, because under maintenance + employee turnover, these little single-purpose functions start growing hairs, and they end up
by barrkel 7y ago
It especially doesn't work in a team, because under maintenance + employee turnover, these little single-purpose functions start growing hairs, and they end up doing more than they're advertised to by name. Next thing you know, you're fetching the same thing from the database in three different functions, or recalculating the same value repeatedly.
Overly granular functions constructed to name blocks of code are a firm anti-pattern in my book.
- emsy 7y agoFunctions overbearing their purpose can be done in large functions too, arguably even easier because it’s harder to express the precise purpose in the function‘s name. And the turnover argument applies to any code convention, which makes it a management issue.
- BurningFrog 7y agoSounds like "team" to you means "dysfunction". I'm sorry you've been in these teams. There are good teams out there!
- barrkel 7y agoOver a multi-year or multi-decade time horizon, it just deteriorates. The oldest codebases I've worked on were 30 years old; the one at my current company is about 10 years old. People come and go, refactorings are started and stopped, bugs are fixed on a tight schedule, and the structure of code divided into nominal blocks slowly dissolves.
- tigershark 7y agoYou can’t make this absolute statement. In functional languages it is actively encouraged to use small, pure and composable functions, as I shown in my previous comment.