4 ms·
The comment that it's about knowledge, not code resonated with me. Like, if you saw Http.getClient(...).doGetRequest(...) a few times, it wouldn't be worth pu
by mrkeen 7y ago
The comment that it's about knowledge, not code resonated with me.
Like, if you saw
Http.getClient(...).doGetRequest(...)
a few times, it wouldn't be worth pulling them out into a myGetRequest(...) method. Your teammates already understand the existing, repeated statements, but they haven't seen myGetRequest(...) before, so you wouldn't be making the code any more readable to them.
But if you had
Http.getClient("auth.myservice.com:8443").doGetRequest(...)
in a few places, then I would pull out the host and port (or maybe the whole line), since it contains knowledge of where/how to authenticate.
Coming from the other direction: if I were reading the code, I can imagine myself looking for the one place where the auth happens, but I can't imagine myself needing to know the one place where Get requests happen (even if the 'Get' code is repeated much more than the 'auth' code)
- masswerk 7y agoI think, you are making a good point for what may be called mutable knowledge. I.e., when writing a shell script to iterate over a few files, nothing of this is of utter importance, since the script is meant to be run only once, thus we may consider any knowledge immutable. Also, maintenance and readability aren't much of a consideration here. In the case of a "real" application, when connecting to an endpoint, as in your example, we may consider address and credentials subject to change, so this is mutable knowledge, which ought to be represented once. However, the method of connecting is hard coded in several places, so it's pretty much immutable. If we expect the method of connecting (http) subject to change, we should consider to put this in a single spot, as well, even, if this may mean that the code may be harder to follow, since we introduced another layer of abstraction. And so on…