5 ms·

I feel like this article ended before it should have. I'm still not exactly sure what the author means by Don't Repeat Knowledge. Should we not be refactoring o

I feel like this article ended before it should have. I'm still not exactly sure what the author means by Don't Repeat Knowledge. Should we not be refactoring or... just don't go overboard?

crispinb 7y ago
I'm still not exactly sure what the author means by Don't Repeat Knowledge I think they're assuming that everyone has read The Pragmatic Programmer. To quote the original DRY principle from there: Every piece of knowledge must have a single, unambiguous, authoritative representation within the system Note that this has only an accidental relationship with code duplication, and in some cases could increase the latter.
- rileymat2 7y ago
  More often than not duplicate code is duplicate knowledge. It often is an implicit business rule that links several statements together or a system requirement like freeing db connections and locks in the right order after use.
  - loopz 7y ago
    DRY skips the part about dependency management: Will tying these parts together make sense for future readability, changability, or not? Often it is wise to be clear what and how to separate and encapsulate. If there is only one right way, there is no reason for change or changing together, so is not shared knowledge.
krisroadruck 7y ago
Hah I'm glad I'm not the only one. I finished reading it and thought that it felt like an intro and they entirely left out the meat of the article. Thought maybe it was just a lack of related knowledge as I just dabble in coding but yeah I figured at some point they would define what it was actually supposed to mean in depth. When that didn't happen I was left wondering what the point of the article was.
- daxfohl 7y ago
  They probably tried to add more info but couldn't do so without repeating some knowledge.
mntmoss 7y ago
When you refactor you are taking shots at moving around where coupling occurs. If your code is maximally decoupled it is primitive copy-paste code that never calls functions and intoduces unique variables for each section - and if it's maximally coupled it will look like swiss cheese, trying to reuse the same functionality for everything with clever parameterization, recursion, indirection and globals. Intentionally coupled code is most common in memory-starved environments since implict dependency helps reduce data overheads. And so "DRY", to the extent that it's useful, encourages you to find slack areas in the code where there's low potential for introducing coupling, and to factor those out so that you have code that is mostly-decoupled without also being redundant and hard to modify - the factoring reflects "knowledge" about the problem. And yet it's not always obvious when you have the knowledge or not. Sometimes redundant-looking code is a form of hardcoded data and a factoring would only push it towards being fully data-driven(which exacts a price in debugging). The Rule of Three is just a common way of making this decision about knowledge.
- novembermike 7y ago
  The issue is that "DRY" isn't actually about coupling at all, it's about creating unambiguous ways to do things. If you have a single http library that's DRY, but if you've got a function that encapsulates several tangentially related bits of code that's not DRY. The acronym just doesn't say what it means.
- temac 7y ago
  If your textual copy past includes some requirements of conforming to a contract, or simply actual copy past of "knowledge" (which can very well also be a under the form of a big textual pattern), the mere form of "primitive copy-paste code that never calls functions and intoduces unique variables for each section" does not actually reduces coupling (except MAYBE if it is expanded down to the metal, including expansion of syscall and/or low level libraries, but you won't do that). Also what have globals anything to do with that, and why do you put them in the supposedly factorized code. You are mistaking it with a bad mess you once saw, maybe? On the other hand, code bases obtained through copy paste based programming can not be considered anything else than a bad mess. But yes, factorizing can be done badly, even to the point of being counterproductive. Like anything.
jschwartzi 7y ago
The actual problem here isn't to refactor or not refactor. The mistake a lot of developers make, including here on HN is in thinking of it mechanistically, that the code is just a bunch of operators and data and we've just gotta push it around the page some without really understanding it. That's how a lot of people interpret DRY, as an end in itself to be accomplished by pushing the symbols around and sweeping them up into something pretty. The most important thing isn't to apply these heuristics, but to understand the problem space in which your code operates before you lay down your abstractions. That's a difficult thing to do without domain knowledge, and in a lot of enterprises you will never get access to the kind of domain knowledge you need to refactor effectively unless you're the lead or in management. To the extent that your code is a series of statements about how the system behaves in response to a particular data input it's easy to read and documents itself. And to the extent that your data structures and statements resemble statements that a domain expert might make(move gantry 30 meters to the left, then drop the crane) they become easy to change in response to changing requirements. Domain knowledge tells you what the fixed elements of the problem space are(is it always a gantry? Does the gantry move in any directions other than left? What does it mean to drop the crane and do we do it different ways?). That informs how you structure your code and what the most clear factoring is. It will not always be the smallest refactoring.
- jmhnilbog 7y ago
  I just wish someone would teach comp sci kids that checking for error conditions is more important than making something look pretty and/or complex.
dllthomas 7y ago
Confusing knowledge for syntax leads us to both false positives and false negatives. An example of each: In designing a web page, if you find yourself saying "there is a button here" in HTML, and in CSS, and in JS, and on the back end, that is not DRY even though the syntax looks nothing alike. Two different APIs, for services serving different purposes controlled by different external entities, happen to have the same structure and you find that a large chunk of code can be factored out of both. I would argue that "what we currently need to do to API 1" is a separate piece of knowledge from "what ... API 2", and unifying them is not DRY.

I feel like this article ended before it should have. I'm still not exactly sure what the author means by Don't Repeat Knowledge. Should we not be refactoring or... just don't go overboard?

crispinb 7y ago

I'm still not exactly sure what the author means by Don't Repeat Knowledge I think they're assuming that everyone has read The Pragmatic Programmer. To quote the original DRY principle from there: Every piece of knowledge must have a single, unambiguous, authoritative representation within the system Note that this has only an accidental relationship with code duplication, and in some cases could increase the latter.

rileymat2 7y ago
More often than not duplicate code is duplicate knowledge. It often is an implicit business rule that links several statements together or a system requirement like freeing db connections and locks in the right order after use.
- loopz 7y ago
  DRY skips the part about dependency management: Will tying these parts together make sense for future readability, changability, or not? Often it is wise to be clear what and how to separate and encapsulate. If there is only one right way, there is no reason for change or changing together, so is not shared knowledge.

krisroadruck 7y ago

Hah I'm glad I'm not the only one. I finished reading it and thought that it felt like an intro and they entirely left out the meat of the article. Thought maybe it was just a lack of related knowledge as I just dabble in coding but yeah I figured at some point they would define what it was actually supposed to mean in depth. When that didn't happen I was left wondering what the point of the article was.

daxfohl 7y ago
They probably tried to add more info but couldn't do so without repeating some knowledge.

mntmoss 7y ago

When you refactor you are taking shots at moving around where coupling occurs. If your code is maximally decoupled it is primitive copy-paste code that never calls functions and intoduces unique variables for each section - and if it's maximally coupled it will look like swiss cheese, trying to reuse the same functionality for everything with clever parameterization, recursion, indirection and globals. Intentionally coupled code is most common in memory-starved environments since implict dependency helps reduce data overheads. And so "DRY", to the extent that it's useful, encourages you to find slack areas in the code where there's low potential for introducing coupling, and to factor those out so that you have code that is mostly-decoupled without also being redundant and hard to modify - the factoring reflects "knowledge" about the problem. And yet it's not always obvious when you have the knowledge or not. Sometimes redundant-looking code is a form of hardcoded data and a factoring would only push it towards being fully data-driven(which exacts a price in debugging). The Rule of Three is just a common way of making this decision about knowledge.

novembermike 7y ago
The issue is that "DRY" isn't actually about coupling at all, it's about creating unambiguous ways to do things. If you have a single http library that's DRY, but if you've got a function that encapsulates several tangentially related bits of code that's not DRY. The acronym just doesn't say what it means.
temac 7y ago
If your textual copy past includes some requirements of conforming to a contract, or simply actual copy past of "knowledge" (which can very well also be a under the form of a big textual pattern), the mere form of "primitive copy-paste code that never calls functions and intoduces unique variables for each section" does not actually reduces coupling (except MAYBE if it is expanded down to the metal, including expansion of syscall and/or low level libraries, but you won't do that). Also what have globals anything to do with that, and why do you put them in the supposedly factorized code. You are mistaking it with a bad mess you once saw, maybe? On the other hand, code bases obtained through copy paste based programming can not be considered anything else than a bad mess. But yes, factorizing can be done badly, even to the point of being counterproductive. Like anything.

jschwartzi 7y ago

The actual problem here isn't to refactor or not refactor. The mistake a lot of developers make, including here on HN is in thinking of it mechanistically, that the code is just a bunch of operators and data and we've just gotta push it around the page some without really understanding it. That's how a lot of people interpret DRY, as an end in itself to be accomplished by pushing the symbols around and sweeping them up into something pretty. The most important thing isn't to apply these heuristics, but to understand the problem space in which your code operates before you lay down your abstractions. That's a difficult thing to do without domain knowledge, and in a lot of enterprises you will never get access to the kind of domain knowledge you need to refactor effectively unless you're the lead or in management. To the extent that your code is a series of statements about how the system behaves in response to a particular data input it's easy to read and documents itself. And to the extent that your data structures and statements resemble statements that a domain expert might make(move gantry 30 meters to the left, then drop the crane) they become easy to change in response to changing requirements. Domain knowledge tells you what the fixed elements of the problem space are(is it always a gantry? Does the gantry move in any directions other than left? What does it mean to drop the crane and do we do it different ways?). That informs how you structure your code and what the most clear factoring is. It will not always be the smallest refactoring.

jmhnilbog 7y ago
I just wish someone would teach comp sci kids that checking for error conditions is more important than making something look pretty and/or complex.

dllthomas 7y ago

Confusing knowledge for syntax leads us to both false positives and false negatives. An example of each: In designing a web page, if you find yourself saying "there is a button here" in HTML, and in CSS, and in JS, and on the back end, that is not DRY even though the syntax looks nothing alike. Two different APIs, for services serving different purposes controlled by different external entities, happen to have the same structure and you find that a large chunk of code can be factored out of both. I would argue that "what we currently need to do to API 1" is a separate piece of knowledge from "what ... API 2", and unifying them is not DRY.