3 ms·

> code I don't understand completely, yet I'm still responsible for it. Is this different than any given library?

by jckahn 1y ago

financetechbro 1y ago
Considering a library is just a component of the application and not the whole application itself. And one can typically understand the inputs and outputs of a library without having to know the detailed functionally of the code behind the library. I would say yes, it is different. But this of course can still open up potential vulnerabilities or unexpected behavior. The way I see it, there is some level of trust behind the library that it was built competently
3np 1y ago
You can and should audit your dependencies.
- alabastervlog 1y ago
  I don't think I've ever seen that actually happen, if you mean reading a meaningful amount of the dep's code. How many teams importing React have even one member who's ever read even a dozen key paths & files in the React codebase? Think it's more than 10%? I'd bet it's closer to 1% than 10%, of teams on which even one member has done that, ever. Do they check the diff for every update? Shit, IME you're lucky if a single person reads the entire changelog before updating, and certainly nobody's reading the diff. Repeat for everything else. Functionally nobody does this, outside niches where small numbers of low-line-count deps are the norm. Rails, all those imports from Square you used to have to use to cut the "WT actual F is this?" rate in Android dev to something non-crazy making, et c. Basically nobody even skims this stuff, and I don't think the number of businesses willing to pay for their developers to do that is large.
  - johnnyanmac 1y ago
    Like any legacy code, understanding the codebase does not mean reading and memorizing every line in the repo. It's a sense of understanding the rough data flow, then having more intimate understandings of the functions you need at that moment. Unlike "vibes" there should always be a sense of purpose on why each function is needed and what you plan to do with the output, even if in some cases you treat hat function like a black box in terms of implementation (which IMO should be avoided, but situations may make the implementation above your understanding).

> code I don't understand completely, yet I'm still responsible for it. Is this different than any given library?

by jckahn 1y ago

> code I don't understand completely, yet I'm still responsible for it. Is this different than any given library?

Considering a library is just a component of the application and not the whole application itself. And one can typically understand the inputs and outputs of a library without having to know the detailed functionally of the code behind the library. I would say yes, it is different. But this of course can still open up potential vulnerabilities or unexpected behavior. The way I see it, there is some level of trust behind the library that it was built competently

3np 1y ago

You can and should audit your dependencies.

alabastervlog 1y ago
I don't think I've ever seen that actually happen, if you mean reading a meaningful amount of the dep's code. How many teams importing React have even one member who's ever read even a dozen key paths & files in the React codebase? Think it's more than 10%? I'd bet it's closer to 1% than 10%, of teams on which even one member has done that, ever. Do they check the diff for every update? Shit, IME you're lucky if a single person reads the entire changelog before updating, and certainly nobody's reading the diff. Repeat for everything else. Functionally nobody does this, outside niches where small numbers of low-line-count deps are the norm. Rails, all those imports from Square you used to have to use to cut the "WT actual F is this?" rate in Android dev to something non-crazy making, et c. Basically nobody even skims this stuff, and I don't think the number of businesses willing to pay for their developers to do that is large.
- johnnyanmac 1y ago
  Like any legacy code, understanding the codebase does not mean reading and memorizing every line in the repo. It's a sense of understanding the rough data flow, then having more intimate understandings of the functions you need at that moment. Unlike "vibes" there should always be a sense of purpose on why each function is needed and what you plan to do with the output, even if in some cases you treat hat function like a black box in terms of implementation (which IMO should be avoided, but situations may make the implementation above your understanding).