3 ms·
The question is, how do those studies measure productivity? In my case, I've found I write more readable, easier to understand code when I use tests to drive o
by heimidal 10y ago
The question is, how do those studies measure productivity?
In my case, I've found I write more readable, easier to understand code when I use tests to drive out my design. It may actually take more time to write the code itself, but the product ends up better, imo.
(Granted, I think I take the approach this article advocates and only do so when I can help inform the design.)
- mcphage 10y ago> In my case, I've found I write more readable, easier to understand code when I use tests to drive out my design. In my case, I've found the opposite—when I use tests to drive my design, I end up with lots of tiny moving parts; each one individually is understandable, but the design as a whole is not, and figuring out how to do anything different is an exercise in frustration. I end up jumping between 2 or 3 files, trying to figure out where anything happens, because it's all been unit tested into perfect isolated pieces.
- z3t4 10y agoI think that when you need to test the code the naive solution is to write less complexed code, witch is a win in itself. In some cases you can get rid of all couplings/complexity and state, so that the code/function/unit never breaks, and writing automated tests for those becomes kinda unnecessary.