Here's my experience with this sort of change: You have exactly one usage where you NEED the update. After deciding to make it you've identified a few other places where you can use the updated code.
The Right Way (TM) to make that change, then, is to make only the change to the result type in the first commit (along with the pattern matching necessary to ignore it), followed by a commit for each place that the updated result type can be usefully used.
Change the code without changing the behavior: i.e. REFACTORING. Run the tests, verify you didn't break anything, then start writing tests for the behavior you wish to change, followed by changing that behavior.
If you think you're at atoms you probably haven't seen strings.
I agree with this, but I'd like to add one more thing. No matter what you do, if you find that your code is hard to change, then change it so that it is less hard. Next time you visit it, change it again. Keep doing this until it is very easy to change the code. Write enough test support in your code that you can do this kind of work safely.
You acknowledge that fact and if you're making a severe change you either run a longer test or you break up the large change into manageable chunks (Google Maps is a great example of this).
For something that is effectively binary and can't be changed incrementally the only way is to extend the evaluation window or make a call with limited information.
I am wary of agreeing with someone with your uname but I have to agree! Go with the project's style, but best is if that style is about the code itself.
I don't care if this was easy or hard or the bug was non-obvious or if you used a weird trick.
I do care what the change does: fixes a race condition, adds a new file mode etc. Those changes matter at the time (what's new in the code?) and when looking backwards (ah, here's where that new file mode was added, let's see what was going on then).
I don't think that scenario is realistic. If you're making a change that doesn't alter a function's output, why is the code for that function being changed at all? That would only be possible if the snapshot didn't capture all the relevant outputs to being with.
Most likely the output will change and you'll be left with a random blob of data to figure out what went wrong instead of clear specifications.
You change the system, and now some part of the application works differently. The way for you to determine if it's expected or not is through the spec of the system. Either it's a bug to have changed it or it wasn't.
In theory, you can use stuff like formal methods while changing a system when you come across things that you think _shouldn't_ change. It's the same concept as tests, really.
In practice I have not found any good tooling for this in production systems. The best alternatives are using types to enforce some rules, and to make APIs that make expressing invalid state impossible. But this is only a small subset of the kind of guarantees you want to have.
No! Never change the behaviour and the implementation at the same time! It is the same for a class or function or monoid or whatever. API change and implementation change should never happen at the same time. If you covered the old behaviour with tests (on the appropriate granularity) you can refactor the IMPLEMENTATION and verify that the systems tested invariants hold buy running the tests. There are a lot of books written about this but really the main idea is this simple.
Beyond having good testing, don't try to write it to be easy to change, write it to be good code.
You should try to express problems elegantly, and that will help make some changes easy. That's nice when that happens, and it does happen quite a bit. But many changes will still not be straightforward.
Generally, write the code to do what it's meant to do, and when it needs to change, rip it out and rewrite it.
It's shockingly easy to write something that's concrete and later realize "I need two of these" and then quickly factor out the common functionality.
Especially, don't kludge things. The problem with "easy to change" is it means "easy to kludge just one more feature on here." That won't remain easy to change. Refactor aggressively and your code still won't be easy to change, but it won't become a kludgey mess that's hard to change, either.
A common purpose of changing something is fixing something that was done wrong.
Consider, for example, fixing the Monad class to subclass Applicative. Or to remove the "fail" or (>>) methods.
This would incur a change to many thousands of lines of code.
Similarly, a core/base type of a whole project can be used across an entire codebase. It is possible to discover desirable changes to such a base type, and it will incur a huge change.
I can think of painful examples in REST in my life where I had an endpoint that was being used for something new, and now I had to join with some new data model to solve the new problem which made the old use sub-optimal (or vice-versa).
But when that happened, what it really told me was that it was time to introduce a new endpoint and refactor the code to adapt to the change in use case. Painful? Sure. But so are the downstream consequences of converting everything in your system to an arbitrary query executor.
You can always chose to change the surrounding code whenever you are adding something to an existing mess, to make a bit less mess. I have heard excuses about not being given time to do it from the management many times before, but the fact is that you are the one who deals with the code, you need to make the decision. If you are not comfortable doing some change, you are the one who needs to be writing the tests or making sure you understand the code. It's not some kind of separate task. It's essential for doing your job right, so you should not expect extra time allocated for it.
Just adding your small change without touching the rest of the application is usually the easiest way, though, so most people just do that instead.
The best rule I have heard is to always leave any code you touch in a better state than you found it.
Write code. It'll likely be bad initially. Don't just write throwaway code, write code that you massage for a while (either rewrite it over and over, or maintain it longer term.). It's when you start to change it on a large scale you notice if it's good or bad. Did you break it when you changed it? Why? Did the changes fall into place easily or was it a pain? Why?
Sometimes I go to change code to do a new thing and it is easy to do. The new cases fit in, the existing system doesn't explode, all is good.
Sometimes the code is beautifully factored and tested. Maybe even documented. It then proceeds to fight against the new change. Maybe the type invariants fail everywhere for reasons that price spurious. Maybe code far away makes dubious assumptions and breaks in response. In the worst case, it's beautiful nonsense held up by undefined behaviour and the language has come to collect the tax.
I like code that can be changed to do new stuff without everything around it exploding. That's probably what I'd call good code. It's in the context of tolerating future requirements well as the future is now.
Surely if the code was unrelated then you wouldn’t have to change it? It might be tangentially related to the change at hand but the fact it breaks means it must be given consideration and not just as a “geez I have to update all these cases” but also in terms of how the change impacts them.
I’m sympathetic to the idea that you want to solve the immediate problem first rather than have to move the entire codebase through several iterations. I’d be interested how well Unison handles that on a complex codebase in reality though.
But, as the system grows, your ability to add or change functionality without breaking things
I disagree unless all your changes are really shallow. You change the structure of your application in significant ways and you'll break the tests too. So now you have two problems.
> I don't really see it is changing coding style to simply have the rename be a discrete commit
Depends on your language, I guess. Changing a Java class name typically involves renaming a file. So if you're doing a refactor, where renaming a class may only be one of several changes you're making 'in the flow', you have to consciously pause after renaming that class and commit.
The problem is the changes you anticipate often are not the changes that happen. Those anticipated-but-not-happening changes waste your time, and also clutter up your code, getting in the way of the changes that do need to be made.
The Right Way (TM) to make that change, then, is to make only the change to the result type in the first commit (along with the pattern matching necessary to ignore it), followed by a commit for each place that the updated result type can be usefully used.
Change the code without changing the behavior: i.e. REFACTORING. Run the tests, verify you didn't break anything, then start writing tests for the behavior you wish to change, followed by changing that behavior.
If you think you're at atoms you probably haven't seen strings.
reply