5 ms·

Refactoring is (or should be) caused by changing requirements, not by the class becoming "too big". Changing requirements come from many places, but tend to be

Refactoring is (or should be) caused by changing requirements, not by the class becoming "too big". Changing requirements come from many places, but tend to be more common in line-of-business applications than free-time programming IME. That is to say: I agree with you, and I think there's some correlation between "software at the mercy of changing business requirements" and "software written in popular class-oriented languages".

lgas 4y ago
The original definition of re-factoring was changing code to improve the quality without changing the behavior. Going by that definition anything you do in response to changing requirements is by definition, not re-factoring. I guess it's just come to mean "changing code" these days, but I think this is regression in terms of expressivity.
- toast0 4y ago
  There's a narrow definition where you may refactor code to allow meeting new requirements, but it doesn't change the behavior for the existing calls. Like, if you go from one type of sort to needing a bunch of different sorts, you might need to make the sorting pluggable, but that shouldn't change the observable behavior of the existing sort type, assuming it gets to stay. That would be a refactoring, plus whatever sorts you needed to plugin.
  - crabmusket 4y ago
    > for each desired change, make the change easy (warning: this may be hard), then make the easy change https://twitter.com/kentbeck/status/250733358307500032 https://twitter.com/kentbeck/status/250733358307500032
- crabmusket 4y ago
  I was being brief above. I agree with you, but allow me to elaborate: I see refactoring as one step in changing code to accommodate new requirements. The refactoring is caused by the changing requirement, but isn't enough by itself to fulfil the new requirement. > improve the quality without changing the behavior IMO, quality cannot be judged without reference to requirements, except in extreme cases. Within a broad range of "code that doesn't make your eyes bleed", comparing one approach to another is difficult to do without reference to how it specifically fulfils the requirements. When requirements change, they may reveal that your existing code doesn't fulfil them well, or doesn't easily generalise, can't be reused, etc. So when you need to change the code, it may first be necessary to do some refactoring. But refactoring without a prompt, without new knowledge entering via changed requirements, is just fiddling with aesthetics.
  - worthless-trash 4y ago
    > is just fiddling with aesthetics. Commonly known as 'making your code more maintainable' so that the following programmers who work on that code do not find your address, look you up and murder you for your crimes against humanity.
    - crabmusket 4y ago
      Every maintenance task is a requirement, in the light of which you should evaluate the quality of existing code! Maintenance isn't just something that hangs around in the air: it is made up of specific goals and activities.
      - worthless-trash 4y ago
        Not in any disagreement with anything you said.
      - lmm 4y ago
        Yes and no. Removing an unused parameter, for example, seems like something that's wise to do for the sake of code maintainability even if one has no specific future tasks/changes in mind. Likewise things like right-length variable names and proper separation of orthogonal concerns. The way I see it, any kind of future maintenance will involve understanding the current code, so unless you expect the code to be abandoned soon, refactoring to improve comprehensibility is legitimate. (Otherwise why even keep the source code at all? If you take the position that there's no point in maintainability without specific maintenance goals, why not keep only the compiled binaries?)
        crabmusket 4y ago
        I content there's something quite different between e.g. removing an unused argument or renaming a variable (both of which should be entirely automated, and hardly count as refactoring) and separation of concerns, which concerns the purpose, architecture and operation of the code. I heartily endorse tidy code, good naming, etc. I would put that, though, in a separate category from refactoring. > Otherwise why even keep the source code at all? If you take the position that there's no point in maintainability without specific maintenance goals, why not keep only the compiled binaries? "Access to source code" is a maintenance goal, it just usually goes without saying and is rarely an issue. It also doesn't involve making any changes to the code, so I'd say it's also in a separate category to refactoring.
eyelidlessness 4y ago
> Refactoring is (or should be) caused by changing requirements This can be a compelling reason to refactor, but my experience is that refactoring is often called for without/before any requirements change. Typical cases: - Existing requirements, and interactions between them, are better understood over time, presenting opportunities to serve them better - Current design/APIs are brittle and adapt poorly to maintenance tasks - Resistance to “premature” abstraction/DRY produces large scale redundancies, and consequently increases volume of bugs and time spent versus value of work - Of course the opposite is true, with improper abstractions becoming unnecessarily entrenched and unwieldy - Ecosystem/stdlib improvements make certain areas of custom code obsolete, or more of a liability than they’re worth
- crabmusket 4y ago
  I'd argue that in all of those cases, the ultimate objective is (or should be!) to serve the requirements. Even maintenance tasks are in service of requirements - if not customer requirements, then internal or environmental ones. Performance can be a requirement too. If requirements aren't changing, the code shouldn't need to change. And if the code doesn't need to change, it doesn't need refactoring.
  - eyelidlessness 4y ago
    The objective is to serve the requirements. The code, inasmuch as it “works”, doesn’t need to change. But the cases I enumerated are ones which frequently enable me to better serve requirements than making no changes. If a given bug fix takes N hours because the underlying code is hard to understand and maintain, it only takes a certain multiple of N before it’s prudent to invest some of those hours into making future fixes possible in N minutes instead. At a certain point, precluding changes on principle is directly opposed to serving requirements.
    - crabmusket 4y ago
      I completely agree with you, and I'm not sure how we're managing to talk past each other. I guess in trying to strongly emphasize a position against "pre-emptive refactoring", maybe I'm coming across as being against ever refactoring or changing the code at all?

lgas 4y ago

The original definition of re-factoring was changing code to improve the quality without changing the behavior. Going by that definition anything you do in response to changing requirements is by definition, not re-factoring. I guess it's just come to mean "changing code" these days, but I think this is regression in terms of expressivity.

toast0 4y ago
There's a narrow definition where you may refactor code to allow meeting new requirements, but it doesn't change the behavior for the existing calls. Like, if you go from one type of sort to needing a bunch of different sorts, you might need to make the sorting pluggable, but that shouldn't change the observable behavior of the existing sort type, assuming it gets to stay. That would be a refactoring, plus whatever sorts you needed to plugin.
- crabmusket 4y ago
  > for each desired change, make the change easy (warning: this may be hard), then make the easy change https://twitter.com/kentbeck/status/250733358307500032 https://twitter.com/kentbeck/status/250733358307500032
crabmusket 4y ago
I was being brief above. I agree with you, but allow me to elaborate: I see refactoring as one step in changing code to accommodate new requirements. The refactoring is caused by the changing requirement, but isn't enough by itself to fulfil the new requirement. > improve the quality without changing the behavior IMO, quality cannot be judged without reference to requirements, except in extreme cases. Within a broad range of "code that doesn't make your eyes bleed", comparing one approach to another is difficult to do without reference to how it specifically fulfils the requirements. When requirements change, they may reveal that your existing code doesn't fulfil them well, or doesn't easily generalise, can't be reused, etc. So when you need to change the code, it may first be necessary to do some refactoring. But refactoring without a prompt, without new knowledge entering via changed requirements, is just fiddling with aesthetics.
- worthless-trash 4y ago
  > is just fiddling with aesthetics. Commonly known as 'making your code more maintainable' so that the following programmers who work on that code do not find your address, look you up and murder you for your crimes against humanity.
  - crabmusket 4y ago
    Every maintenance task is a requirement, in the light of which you should evaluate the quality of existing code! Maintenance isn't just something that hangs around in the air: it is made up of specific goals and activities.
    - worthless-trash 4y ago
      Not in any disagreement with anything you said.
    - lmm 4y ago
      Yes and no. Removing an unused parameter, for example, seems like something that's wise to do for the sake of code maintainability even if one has no specific future tasks/changes in mind. Likewise things like right-length variable names and proper separation of orthogonal concerns. The way I see it, any kind of future maintenance will involve understanding the current code, so unless you expect the code to be abandoned soon, refactoring to improve comprehensibility is legitimate. (Otherwise why even keep the source code at all? If you take the position that there's no point in maintainability without specific maintenance goals, why not keep only the compiled binaries?)
      - crabmusket 4y ago
        I content there's something quite different between e.g. removing an unused argument or renaming a variable (both of which should be entirely automated, and hardly count as refactoring) and separation of concerns, which concerns the purpose, architecture and operation of the code. I heartily endorse tidy code, good naming, etc. I would put that, though, in a separate category from refactoring. > Otherwise why even keep the source code at all? If you take the position that there's no point in maintainability without specific maintenance goals, why not keep only the compiled binaries? "Access to source code" is a maintenance goal, it just usually goes without saying and is rarely an issue. It also doesn't involve making any changes to the code, so I'd say it's also in a separate category to refactoring.

eyelidlessness 4y ago

> Refactoring is (or should be) caused by changing requirements This can be a compelling reason to refactor, but my experience is that refactoring is often called for without/before any requirements change. Typical cases: - Existing requirements, and interactions between them, are better understood over time, presenting opportunities to serve them better - Current design/APIs are brittle and adapt poorly to maintenance tasks - Resistance to “premature” abstraction/DRY produces large scale redundancies, and consequently increases volume of bugs and time spent versus value of work - Of course the opposite is true, with improper abstractions becoming unnecessarily entrenched and unwieldy - Ecosystem/stdlib improvements make certain areas of custom code obsolete, or more of a liability than they’re worth

crabmusket 4y ago
I'd argue that in all of those cases, the ultimate objective is (or should be!) to serve the requirements. Even maintenance tasks are in service of requirements - if not customer requirements, then internal or environmental ones. Performance can be a requirement too. If requirements aren't changing, the code shouldn't need to change. And if the code doesn't need to change, it doesn't need refactoring.
- eyelidlessness 4y ago
  The objective is to serve the requirements. The code, inasmuch as it “works”, doesn’t need to change. But the cases I enumerated are ones which frequently enable me to better serve requirements than making no changes. If a given bug fix takes N hours because the underlying code is hard to understand and maintain, it only takes a certain multiple of N before it’s prudent to invest some of those hours into making future fixes possible in N minutes instead. At a certain point, precluding changes on principle is directly opposed to serving requirements.
  - crabmusket 4y ago
    I completely agree with you, and I'm not sure how we're managing to talk past each other. I guess in trying to strongly emphasize a position against "pre-emptive refactoring", maybe I'm coming across as being against ever refactoring or changing the code at all?