I know the author ended up with code that was the same speed at the end of all this, but if you're ever intentionally refactoring code just to make testing easier (and not to aid in the readability or overall architecture) isn't that usually a bad design decision? Further, if you're intentionally refactoring code that you know may slow it down 2x just to aid in writing tests, isn't that a bad reason to refactor that code?
> The result library is often slower than pure C (~2x magnitude) but still having a native Go port could simplify some aspects of the workflow like testing.
In my experience, being difficult to test is a sign that a refactor is needed anyways.
Difficulty testing also creates a higher barrier to adding new features. If you can't test something, it reduces confidence that your change won't break it.
If it's an extremely performance-sensitive component, then you'd obviously want to be very cautious about big changes. However, that's usually not the case.
Nope, if code wasnt testable, code was less valuable. Overall architecture doesnt bring client, doesnt ease test, doesn't speed up development, etc: it can be just a pretty picture on the architect's wall while everyone is miserable. Refactor for testing.
Agreed if it's gonna double the time spent per unit of work, compromise. Do not care about the architect's pretty picture, he's not solving clients' problem, you are.
> The result library is often slower than pure C (~2x magnitude) but still having a native Go port could simplify some aspects of the workflow like testing.