4 ms·

uhhh tricky if your codebase is 3 features each of which has 3 similar functions (listener, db model, middleware, let's say) do you group by similar functions

uhhh tricky if your codebase is 3 features each of which has 3 similar functions (listener, db model, middleware, let's say) do you group by similar functions? (middlewares.py, models.py)? or do you group by feature? (feature1.py). depending on whether 'work' is a feature change or a refactor this week, the correlations will be different

kerblang 5y ago
A lot of programmers want to divide logic into Categories of Behavior and then package them up into behavior packages, so that you have to hopscotch all over the directory tree to reconstruct and navigate an actual process from beginning to end; then they want to chop it all up into microservices in an attempt to compensate for the resulting mess. If you package logic according to the process, it's a lot easier to control the scope of logic that is exclusive to a given process (some things are of course shared). Languages that can enforce package privacy, file privacy, etc. help a lot here. In general, unlimited scope & dependencies is what strangles a dev team to death, so any option that restricts scope to what is necessary is arguably best.
- awinter-py 5y ago
  by process, you mean call stack or series of event handoffs? I think you're right that that's one of the key ways that devs (esp noobs to the codebase) need to navigate, and must be supported. I think 'stack graphs' are supposed to do that[1], but have never tried them. but there are other navigation modes we need to support as well -- like if you're deleting something, or upgrading something, 'find all references'. if you're inventorying use of a DB type, you might want to audit field types in all models. I sometimes wonder if the future is tagging code as 'belonging to a feature', but they can live wherever -- because devs have different needs on different days. [1] https://dcreager.net/talks/2021-strange-loop/ https://dcreager.net/talks/2021-strange-loop/
  - kerblang 5y ago
    By process I typically mean "business process", as in: Bob wants to ship all the widgets to the South Warehouse, and this pile of logic right here is going to do that for him, end-to-end (or mostly end-to-end). The best option I've found for "find everything that references this database table and see if it will be affected by this thing I need to change" is to give database tables really unique names (like "tbl_user" instead of "user") and just grep the hell out of everything. Also if I'm writing large programs I'm going to use a compiler. I mean if a linter can tell you "Hey this python won't work because you removed this function" then good for python, otherwise bad for python. And if I'm going to include 100 open-source libraries then god help me if my build system can't tell that one of them went missing or that the author removed a function I'm using in version 1.2.3.4.b. But all of that is about dependencies, and dependencies kill teams. That's why I want the scope of any logic as tightly constrained and enforced as possible. I'm sure you could design a multi-dimensional behavioral categorizer/IDE/language system that blows everybody's minds and wouldn't that be cool, but I doubt anyone would use it, because behavioral categorization really doesn't solve problems. It just looks nice. But any rate, at the very minimum, back to this point: Don't try to compensate for the failure of behavioral categorization with microservices when you could have just packaged things along the same lines of division.
    - awinter-py 5y ago
      100% with you on greppability as an underrated design skill interested in 'library versions as types' and have been thinking about this problem on and off. version numbers are a proxy for the combination of: 1) call signature, and 2) internal semantics linters / typesystems are good at (1). If we had a system that could do (2), version numbers would be less necessary and compatibility could be proof-based. (Well, to the extent that the semantic assertions are valid).

kerblang 5y ago

A lot of programmers want to divide logic into Categories of Behavior and then package them up into behavior packages, so that you have to hopscotch all over the directory tree to reconstruct and navigate an actual process from beginning to end; then they want to chop it all up into microservices in an attempt to compensate for the resulting mess. If you package logic according to the process, it's a lot easier to control the scope of logic that is exclusive to a given process (some things are of course shared). Languages that can enforce package privacy, file privacy, etc. help a lot here. In general, unlimited scope & dependencies is what strangles a dev team to death, so any option that restricts scope to what is necessary is arguably best.

awinter-py 5y ago
by process, you mean call stack or series of event handoffs? I think you're right that that's one of the key ways that devs (esp noobs to the codebase) need to navigate, and must be supported. I think 'stack graphs' are supposed to do that[1], but have never tried them. but there are other navigation modes we need to support as well -- like if you're deleting something, or upgrading something, 'find all references'. if you're inventorying use of a DB type, you might want to audit field types in all models. I sometimes wonder if the future is tagging code as 'belonging to a feature', but they can live wherever -- because devs have different needs on different days. [1] https://dcreager.net/talks/2021-strange-loop/ https://dcreager.net/talks/2021-strange-loop/
- kerblang 5y ago
  By process I typically mean "business process", as in: Bob wants to ship all the widgets to the South Warehouse, and this pile of logic right here is going to do that for him, end-to-end (or mostly end-to-end). The best option I've found for "find everything that references this database table and see if it will be affected by this thing I need to change" is to give database tables really unique names (like "tbl_user" instead of "user") and just grep the hell out of everything. Also if I'm writing large programs I'm going to use a compiler. I mean if a linter can tell you "Hey this python won't work because you removed this function" then good for python, otherwise bad for python. And if I'm going to include 100 open-source libraries then god help me if my build system can't tell that one of them went missing or that the author removed a function I'm using in version 1.2.3.4.b. But all of that is about dependencies, and dependencies kill teams. That's why I want the scope of any logic as tightly constrained and enforced as possible. I'm sure you could design a multi-dimensional behavioral categorizer/IDE/language system that blows everybody's minds and wouldn't that be cool, but I doubt anyone would use it, because behavioral categorization really doesn't solve problems. It just looks nice. But any rate, at the very minimum, back to this point: Don't try to compensate for the failure of behavioral categorization with microservices when you could have just packaged things along the same lines of division.
  - awinter-py 5y ago
    100% with you on greppability as an underrated design skill interested in 'library versions as types' and have been thinking about this problem on and off. version numbers are a proxy for the combination of: 1) call signature, and 2) internal semantics linters / typesystems are good at (1). If we had a system that could do (2), version numbers would be less necessary and compatibility could be proof-based. (Well, to the extent that the semantic assertions are valid).