4 ms·

> no one knows where it's used ... Isn't this really a tooling problem? I can't imagine any environment in which I can't instantly find all callers/users of a

> no one knows where it's used ... Isn't this really a tooling problem? I can't imagine any environment in which I can't instantly find all callers/users of a shared package. The problem I always have is that there are too many [known] callers! Impact is still unknown because you can't always depend on unit and other test to uncover complex issues unforeseen and unknown until they actually crop up. But that's why you have a staging environment. It's better than the alternative of not sharing code.

bigiain 5y ago
> I can't imagine any environment in which I can't instantly find all callers/users of a shared package All the people who spent that last week or two hunting down places where log4j got imported by dependencies like Springboot or Grails are crying into their Xmas whisky at this…
- samus 5y ago
  Had that job, and I disagree. Maven Dependency plugin has got you there. `dependency:tree` even shows you which library brought it along. The difficult part was how to make dependency versions from `log4j-bom` win over the `spring-boot-dependencies` BOM. Also, one or two places in the code actually used some utility functions from `log4j-core`...
  - Xylakant 5y ago
    But the problem is the inverse one: given a library, which project in your org depends on it? Possibly a project tucked away into a repository that a developer maintained that just left last week and that just happens to be deployed on an external facing web server. It’s easier for Java based apps since you can just scan the machines they’re deployed on, but it’s hard for C and the like.
    - samus 5y ago
      Yeah, there was also a deployable that ops almost forgot about, but I remembered. But even in C, you can inspect the symbol table of binaries. Unless they got stripped or optimized away, of course. Edit: yes, deployables that nobody knows about and just sit there for years are a huge problem.
      - mst 5y ago
        Provided the dependency is dynamically linked, you can find everything running against an old version of the .so after it's been updated by using the 'checkrestart' command. A combination of unattended-upgrades and periodic checkrestart runs makes my life as a debuntu admin much easier. Note: Yes, I know how many environments this doesn't apply to. But if one person whose environment it does apply to discovers the joy of 'checkrestart' as a result of this comment, it was still worth typing out :D
onion2k 5y ago
It's better than the alternative of not sharing code. Some complex things need to be shared, but something like a library to make directory structures doesn't. It's fine if teams just write their own, or use one from outside the company. At least that way any issues are limited to only impacting that team, and in the long term you end up with much more maintainable apps. Shared code that isn't treated like an external library(with proper, defined maintainers) is, in my experience, some of the worst technical debt.
- alecbz 5y ago
  > but something like a library to make directory structure As others comments point out, doing this well is subtle and tricky. This is absolutely the kind of thing that individual teams ought not have to maintain their own copies of. Agree the best solution would be for this to be baked into the language, or failing that a well-known OSS library. But if you don't have either, a shared company library is better than the duplication IMO. It does require a company culture that's able to invest in infrastructure, but I think you need that, especially if you're working with languages like C that don't come with as many "batteries included".

bigiain 5y ago

> I can't imagine any environment in which I can't instantly find all callers/users of a shared package All the people who spent that last week or two hunting down places where log4j got imported by dependencies like Springboot or Grails are crying into their Xmas whisky at this…

samus 5y ago
Had that job, and I disagree. Maven Dependency plugin has got you there. `dependency:tree` even shows you which library brought it along. The difficult part was how to make dependency versions from `log4j-bom` win over the `spring-boot-dependencies` BOM. Also, one or two places in the code actually used some utility functions from `log4j-core`...
- Xylakant 5y ago
  But the problem is the inverse one: given a library, which project in your org depends on it? Possibly a project tucked away into a repository that a developer maintained that just left last week and that just happens to be deployed on an external facing web server. It’s easier for Java based apps since you can just scan the machines they’re deployed on, but it’s hard for C and the like.
  - samus 5y ago
    Yeah, there was also a deployable that ops almost forgot about, but I remembered. But even in C, you can inspect the symbol table of binaries. Unless they got stripped or optimized away, of course. Edit: yes, deployables that nobody knows about and just sit there for years are a huge problem.
    - mst 5y ago
      Provided the dependency is dynamically linked, you can find everything running against an old version of the .so after it's been updated by using the 'checkrestart' command. A combination of unattended-upgrades and periodic checkrestart runs makes my life as a debuntu admin much easier. Note: Yes, I know how many environments this doesn't apply to. But if one person whose environment it does apply to discovers the joy of 'checkrestart' as a result of this comment, it was still worth typing out :D

onion2k 5y ago

It's better than the alternative of not sharing code. Some complex things need to be shared, but something like a library to make directory structures doesn't. It's fine if teams just write their own, or use one from outside the company. At least that way any issues are limited to only impacting that team, and in the long term you end up with much more maintainable apps. Shared code that isn't treated like an external library(with proper, defined maintainers) is, in my experience, some of the worst technical debt.

alecbz 5y ago
> but something like a library to make directory structure As others comments point out, doing this well is subtle and tricky. This is absolutely the kind of thing that individual teams ought not have to maintain their own copies of. Agree the best solution would be for this to be baked into the language, or failing that a well-known OSS library. But if you don't have either, a shared company library is better than the duplication IMO. It does require a company culture that's able to invest in infrastructure, but I think you need that, especially if you're working with languages like C that don't come with as many "batteries included".