The best you can do is to have automatic tests, lots of them, and make them work as intended (good tests are very hard to make). Those make refactoring possible and make specific quality guaranties.
I don’t know much physics, but this word-soup about entropy is mistaken, isn’t it? Because something something about closed systems vs open systems and putting energy into systems (eg, people working on the codebase)?
> The best you can do is to have automatic tests, lots of them, and make them work as intended (good tests are very hard to make).
I’m not sure what “best” means here, but there are other tools for improving software quality beyond tests, including and in particular formal methods.
> Those [tests] make refactoring possible and make specific quality guaranties.
What quality guarantees do tests make? That the build passes the test suite?
> Because something something about closed systems vs open systems and putting energy into systems (eg, people working on the codebase)?
Did you ever lead a project that spans at least half decade? And is this a coherent thought or something something whatever?
> I’m not sure what “best” means here, but there are other tools for improving software quality beyond tests, including and in particular formal methods.
There are other tools, but the one that makes refactoring possible is the best you can do regarding OP question. If you have a bad quality code, you need to refactor, no? You might want to have some other tools like superb docs, formal proofs etc. but those do next to 0 when you need to refactor and guarantee that you didn't break hell.
> What quality guarantees do tests make? That the build passes the test suite?
Notice the part about "good tests" which are "very hard" to do.
I’ll retract my comment about formal methods since I’ve never actually used them in a refactor. And I agree that tests make refactoring easier. But none of this demonstrates for me that tests are the “best” tool for facilitating a refactor.
And so, what specific quality guarantees do good tests make?
Entropy is a scientific concept as well as a measurable physical property that is most commonly associated with a state of disorder, randomness, or uncertainty
What is your claim, that disorder, randomness and uncertainty DO NOT build up with time? :)
> And I agree that tests make refactoring easier.
They don't make it easier. They make it POSSIBLE.
> And so, what specific quality guarantees do good tests make?
Good tests cover all critical sections of functional specification (what is deemed critical depends on project). If you have functional rules x, y and z somewhere there, there need to be bunch of tests for x, y and z somewhere, ideally fuzzy, fast and without blank database.
This is all very much basic IT stuff for long time, particularly nowadays when software needs to run not only in your basement but on every conservable device and number of different contexts!
No offense, but you seem new in this business, and your aggression doesn't help at all.
It depends on the system. Claiming that disorder builds up in all systems is false, afaik. From a Google search: Entropy increases in a closed system. In open systems, the entropy is kept low, or decreases
Are you claiming that codebases are closed systems?
> They don't make them easier. They make them POSSIBLE.
Are you arguing about the definition of “easier” or just trying to rhetorically emphasize the impact of tests on refactoring?
Would you agree if I said tests make refactoring A LOT easier?
Seems like we both agree that we’d rather refactor a system with tests than without (all else the same).
> Good tests cover all critical sections of functional specification (what is deemed critical depends on project). If you have functional rules x, y and z somewhere there, there need to be bunch of tests for x, y and z somewhere, ideally fuzzy, fast and without blank database.
You’ve told me what parts of the code you want to test, but not what guarantees the tests make.
> No offense, but you seem new in this business, and your aggression doesn't help at all.
You’re right I’m new. Thanks for your patience.
If we accept this analogy, then with enough care, a software project can improve in quality (paying off technical debt for example, or extensive code reviews by experts). But even letting go of this possibly flawed analogy, while there is a tendency of entropy-build up, very easily observable in my home folder, there exist software projects that do improve in quality over time.
I don't deal with academic theory and strange special cases - I deal with real, everyday world. You can basically argue out any position if you are clever enough but that doesn't prove anything except that you are clever.
As software systems (like many systems) go from initial development (which may or may not have a solid vision and initially highly disciplined development approach) to long term maintenance, disorder creeps into the system. Often just as a matter of expedience, "Let me make this field public so this other module can modify it directly because I need it now, I'll come up with a proper interface later. Oh shit, three years later 100 modules are making use of that public field."
What tests do, in this case, is help to preserve order. They help to ensure that a more rigid and ordered structure for the code remains. Formal methods only take you so far because, outside of maybe coq and related languages, there is no direct connection between your formal method spec and the code that has been written, in contrast to tests (which can be derived from your formal spec, but usually manually). Of course, tests can only carry you so far, they also have to be maintained. If a test is removed because it's no longer relevant, is another test put in its place to verify the new system? Are tests disabled because they're only failing sporadically or because the bugs they represent are hard to fix and we don't know how to yet (or don't have the time)?
Gradually, a system starts to suffer from various problems of this sort, that's entropy. Maintaining quality is a constant struggle against various forces (convenience, loss of institutional knowledge, time pressure, etc.). Tests are one way (and a critical way) to help balance against those forces.
EDIT: Other formal methods that work with real systems would be in Ada/SPARK, ATS, or Frama-C and I'm surprised I didn't mention them above. However, at least with SPARK, it narrows the scope of what you can do with the system and prove properties about it. That scope is always increasing, but is still a subset of what Ada itself can do. That's not all bad, but this means you can only consistently prove (in a formal sense) properties of subsets of a larger system and will likely be unable to prove (in an automatic fashion at least) a significant number of properties of those same larger systems.