3 ms·

I like the boy scout rule. Clean up and leave it nicer than you found it. Focused mostly on things related to your change. Big rewrites cause big issues.

by carlmr 8y ago

pmarreck 8y ago
> Big rewrites cause big issues. Those issues are very much constrained by a very good test suite.
- waterlink 8y ago
  Unless your test suite needs a rewrite, as well… (Better refactor, of course)
  - camgunz 8y ago
    Your test suite should essentially be your requirements. If it's out of date, it's the first thing you should update. Adding features or changing your requirements without updating your tests is the essence of tech debt: you're delivering features quickly at the expense of future work and brittleness. I agree it's pretty common though. I've also seen huge test suites of only unit tests, no integration tests. As a result, you have no assurance that your refactors work because changing the inner workings fundamentally requires you to change the unit tests too, and nothing checks the top-level interface.
  - Shorel 8y ago
    You either rewrite the tests, or the code. Not both at the same time, in my opinion.
- collyw 8y ago
  You mean a test suite that will take longer to write than the rewrite?
  - maxxxxx 8y ago
    He means one that slowly goes out of date because nobody has the time to change it when the requirements change.
- carlmr 8y ago
  I'm just going to ask which company you've been at that a) needed a big rewrite and b) had a "very good test suite". In my experience there's not much overlap here, especially because one of the reasons why a) is necessary is often that there's so little modularization that b) is not possible to exist.
  - pmarreck 8y ago
    > a) needed a big rewrite and b) had a "very good test suite" Desk.com has a gigantic Rails codebase and a test suite that runs for... well when I left them it was 40 minutes long but it's probably longer now. But it did save us many many times. I'm working at another company right now (can't disclose) and they also have a rather large Rails codebase and a fairly good test suite. I think the Rails community historically has been pretty great at communicating good test/design decisions, so the modularization issue you mentioned is largely moot.
    - carlmr 8y ago
      Like I said, you wouldn't want a huge refactor of the code there, because it's already tested and probably very testable the way it is. Otherwise it wouldn't have this good test suite. Modularization is the issue, not size. If you have a big project and it's nicely modularized you probably already have good tests for it, but don't need to refactor. If it's big and needs a huge refactor it's probably hard to test and doesn't have appropriate tests.

I like the boy scout rule. Clean up and leave it nicer than you found it. Focused mostly on things related to your change. Big rewrites cause big issues.

by carlmr 8y ago

I like the boy scout rule. Clean up and leave it nicer than you found it. Focused mostly on things related to your change. Big rewrites cause big issues.

pmarreck 8y ago

> Big rewrites cause big issues. Those issues are very much constrained by a very good test suite.

waterlink 8y ago
Unless your test suite needs a rewrite, as well… (Better refactor, of course)
- camgunz 8y ago
  Your test suite should essentially be your requirements. If it's out of date, it's the first thing you should update. Adding features or changing your requirements without updating your tests is the essence of tech debt: you're delivering features quickly at the expense of future work and brittleness. I agree it's pretty common though. I've also seen huge test suites of only unit tests, no integration tests. As a result, you have no assurance that your refactors work because changing the inner workings fundamentally requires you to change the unit tests too, and nothing checks the top-level interface.
- Shorel 8y ago
  You either rewrite the tests, or the code. Not both at the same time, in my opinion.
collyw 8y ago
You mean a test suite that will take longer to write than the rewrite?
- maxxxxx 8y ago
  He means one that slowly goes out of date because nobody has the time to change it when the requirements change.
carlmr 8y ago
I'm just going to ask which company you've been at that a) needed a big rewrite and b) had a "very good test suite". In my experience there's not much overlap here, especially because one of the reasons why a) is necessary is often that there's so little modularization that b) is not possible to exist.
- pmarreck 8y ago
  > a) needed a big rewrite and b) had a "very good test suite" Desk.com has a gigantic Rails codebase and a test suite that runs for... well when I left them it was 40 minutes long but it's probably longer now. But it did save us many many times. I'm working at another company right now (can't disclose) and they also have a rather large Rails codebase and a fairly good test suite. I think the Rails community historically has been pretty great at communicating good test/design decisions, so the modularization issue you mentioned is largely moot.
  - carlmr 8y ago
    Like I said, you wouldn't want a huge refactor of the code there, because it's already tested and probably very testable the way it is. Otherwise it wouldn't have this good test suite. Modularization is the issue, not size. If you have a big project and it's nicely modularized you probably already have good tests for it, but don't need to refactor. If it's big and needs a huge refactor it's probably hard to test and doesn't have appropriate tests.