3 ms·

A corollary of "if it ain't broke don't fix it" is "if you can't read it don't refactor it." http://www.joelonsoftware.com/articles/fog0000000069.html http://w

by rqebmm 11y ago

A corollary of "if it ain't broke don't fix it" is "if you can't read it don't refactor it." http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

munificent 11y ago
It really bugs me that "refactoring" has been taken to mean any code change (hopefully) without end-user visible effect. We didn't need a new word for that. Refactoring is about doing that in a rigously reliable way. My rule is, if you don't have good tests, you aren't "refactoring" you're "moving shit around and praying you don't break something".
- jeremiep 11y ago
  My rule is: tests only check the presence of bugs, not their absence. And is usually little more than wishful thinking to delude people into believing their code to be bug-free. Understanding the code is worth WAY more than having good tests. Most of the great programmers who inspire me don't write tests but have the deepest understanding of whats going on.
  - npizzolato 11y ago
    I've seen far more problems from people who think they understand the code so they don't need tests than from people who write tests to check their code. The best of the best might be able to get by without tests, but us common-folk stand to benefit a lot from writing tests and listening to the design feedback they provide.
    - jeremiep 11y ago
      While I agree with the general idea in theory, I haven't seen it happen that often in practice. More often than not tests will constrain the architecture of the actual system and result in code that is much more complex than what is required to solve the problem at hand. People then start having blind faith in their tests while being completely oblivious to what they don't test. At that point the codebase is such a mess that you do need tests to maintain it. People who focus on understanding their code work very, very hard to keep their codebase simple enough to quickly wrap their heads around it. I know I modify my codebase way too much for it to have tests - I'd spend more time refactoring the tests than progressing and I wouldn't be able to simplify the architecture as much because my attention is now on how testable the code is rather than how simple it is. I see projects shipped with unittests that still required maintenance and debugging 6 months down the road, and others without tests that worked flawlessly out the door. Of course, there's a difference between understanding and thinking you understand, but that's another matter entirely as we're walking into Dunning-Kruger territory! I'm not saying tests are bad! Far from it, I do write tests for functions where the logic isn't obvious, but my point is that there's too much focus on testing and not enough on actual quality and simplicity.
      - munificent 11y ago
        Sounds like a lot of projects you worked on had tests at the wrong granularity. Fine grained unit tests are good for helping you find out where a bug is in the code, at the expense of calcifying your architecture. "Functional", "integration", "end-to-end" or other higher level tests don't pinpoint a bug as easily but in return they give you greater freedom to reorganize your implementation. For example, I work on a code formatter: https://github.com/dart-lang/dart_style https://github.com/dart-lang/dart_style It has a metric ton of tests, which is absolutely critical for ensuring a change to one corner of the formatting doesn't regress other things. Formatting is solving a bunch of global constraints, so almost every change interacts with other things. I've rewritten almost the whole thing twice at this point, and the tests never slowed me down. That's because they're functional tests: they just run the formatter and validate the expected output. It does mean I spent a hell of a lot more time figuring out why some test was failing, but it made refactoring a joy.
  - ilurk 11y ago
    Everyone thinks they understand what they are implementing but then inevitably encounter some unexpected "feature". Tests help, but yeah... halting problem. As for those great programmers how many sloc can they write without any compilation error and have the application executing as intended? If they make mistakes then bugs can also happen. It's only a matter of code complexity.
  - krylon 11y ago
    > Most of the great programmers who inspire me don't write tests but have the deepest understanding of whats going on. Understanding the code and having tests is not mutually exclusive. And if you have ever inherit a code base from somebody who "didn't need to write tests", because he or she understood the code so well, you will come to appreciate tests in a whole new way. ;-)
  - munificent 11y ago
    > Most of the great programmers who inspire me don't write tests but have the deepest understanding of whats going on. The programmers who inspire me deeply understand their code and their own fallibility so they also write tests.
- Tloewald 11y ago
  Refactoring is abused as a handy word to use to describe random shit that would confuse management if you went into detail. If you're genuinely refactoring then, depending on the scope of the refactoring and the nature of the code being refactored, I would agree. Making that judgment is part of being good at your job. But "refactoring" often means "cleaning up some really shitty code we wrote in haste last month now that we aren't facing a horrible deadline", and that's worth doing with or without good tests. And using a nice opaque term like refactoring stops your having to explain "good, fast, cheap" to some manager like he/she is stupid (which he/she is not) for the umpteenth time.

by rqebmm 11y ago

munificent 11y ago

It really bugs me that "refactoring" has been taken to mean any code change (hopefully) without end-user visible effect. We didn't need a new word for that. Refactoring is about doing that in a rigously reliable way. My rule is, if you don't have good tests, you aren't "refactoring" you're "moving shit around and praying you don't break something".

jeremiep 11y ago
My rule is: tests only check the presence of bugs, not their absence. And is usually little more than wishful thinking to delude people into believing their code to be bug-free. Understanding the code is worth WAY more than having good tests. Most of the great programmers who inspire me don't write tests but have the deepest understanding of whats going on.
- npizzolato 11y ago
  I've seen far more problems from people who think they understand the code so they don't need tests than from people who write tests to check their code. The best of the best might be able to get by without tests, but us common-folk stand to benefit a lot from writing tests and listening to the design feedback they provide.
  - jeremiep 11y ago
    While I agree with the general idea in theory, I haven't seen it happen that often in practice. More often than not tests will constrain the architecture of the actual system and result in code that is much more complex than what is required to solve the problem at hand. People then start having blind faith in their tests while being completely oblivious to what they don't test. At that point the codebase is such a mess that you do need tests to maintain it. People who focus on understanding their code work very, very hard to keep their codebase simple enough to quickly wrap their heads around it. I know I modify my codebase way too much for it to have tests - I'd spend more time refactoring the tests than progressing and I wouldn't be able to simplify the architecture as much because my attention is now on how testable the code is rather than how simple it is. I see projects shipped with unittests that still required maintenance and debugging 6 months down the road, and others without tests that worked flawlessly out the door. Of course, there's a difference between understanding and thinking you understand, but that's another matter entirely as we're walking into Dunning-Kruger territory! I'm not saying tests are bad! Far from it, I do write tests for functions where the logic isn't obvious, but my point is that there's too much focus on testing and not enough on actual quality and simplicity.
    - munificent 11y ago
      Sounds like a lot of projects you worked on had tests at the wrong granularity. Fine grained unit tests are good for helping you find out where a bug is in the code, at the expense of calcifying your architecture. "Functional", "integration", "end-to-end" or other higher level tests don't pinpoint a bug as easily but in return they give you greater freedom to reorganize your implementation. For example, I work on a code formatter: https://github.com/dart-lang/dart_style https://github.com/dart-lang/dart_style It has a metric ton of tests, which is absolutely critical for ensuring a change to one corner of the formatting doesn't regress other things. Formatting is solving a bunch of global constraints, so almost every change interacts with other things. I've rewritten almost the whole thing twice at this point, and the tests never slowed me down. That's because they're functional tests: they just run the formatter and validate the expected output. It does mean I spent a hell of a lot more time figuring out why some test was failing, but it made refactoring a joy.
- ilurk 11y ago
  Everyone thinks they understand what they are implementing but then inevitably encounter some unexpected "feature". Tests help, but yeah... halting problem. As for those great programmers how many sloc can they write without any compilation error and have the application executing as intended? If they make mistakes then bugs can also happen. It's only a matter of code complexity.
- krylon 11y ago
  > Most of the great programmers who inspire me don't write tests but have the deepest understanding of whats going on. Understanding the code and having tests is not mutually exclusive. And if you have ever inherit a code base from somebody who "didn't need to write tests", because he or she understood the code so well, you will come to appreciate tests in a whole new way. ;-)
- munificent 11y ago
  > Most of the great programmers who inspire me don't write tests but have the deepest understanding of whats going on. The programmers who inspire me deeply understand their code and their own fallibility so they also write tests.
Tloewald 11y ago
Refactoring is abused as a handy word to use to describe random shit that would confuse management if you went into detail. If you're genuinely refactoring then, depending on the scope of the refactoring and the nature of the code being refactored, I would agree. Making that judgment is part of being good at your job. But "refactoring" often means "cleaning up some really shitty code we wrote in haste last month now that we aren't facing a horrible deadline", and that's worth doing with or without good tests. And using a nice opaque term like refactoring stops your having to explain "good, fast, cheap" to some manager like he/she is stupid (which he/she is not) for the umpteenth time.