4 ms·
Why should other test your code?
by mic47 8y ago
Why should other test your code?
- ben-schaaf 8y agoSame reason you don't review your own code, or pair program by talking to yourself.
- koolba 8y ago> ... or pair program by talking to yourself. Who says I don’t? https://en.m.wikipedia.org/wiki/Rubber_duck_debugging https://en.m.wikipedia.org/wiki/Rubber_duck_debugging
- icebraining 8y agoIt's not pair programming, though, even if can have some of its advantages.
- mic47 8y agoYou can solve this by test plan: You write into test plan what you have tested, and others in code review can suggest/require to test other things you missed. In my previous job this worked quite well.
- icebraining 8y agoThat's fair enough; I think when people are talking about manual testing, they're thinking about the decision of what should be tested, not the actual button pressing. But it's a distinction worth making.
- stinos 8y agoThis seems a bit of a false generalization to me. For a long time I've been the sole developer on multiple large-ish applications. So of course I review my own code, and I write my own tests. And yes as another commenter mentions: if you don't pay attention this can lead to tunnel vision, and yes it can be hard to be consistent about it. I discovered those drawbacks fairly early, so quickly made it a habit to be super-strict and critical about pretty much every single line of code I write (both with regards to style, functionality, how it adheres to the standard practices etc). What I also do consistently is review older code: if I have to add a function to existing code, it happens more often than not that I'll re-read and review the surrounding bits. Often to come up with better code. If time permits, else I take note and go back to it later. In practice it turns out that if I haven't touched code for months, reviewing it is almost the same as reviewing someone else's code, i.e. starting with a clean slate. Which is also why I'll sometimes write something, commit it, but not yet merge it to production. Then a week or so later I'll come back and review every bit again.
- ben-schaaf 8y agoOh, I completely agree, though I wouldn't call writing code carefully and methodically a "code review" if that makes sense. I personally find that me a couple months down the track is pretty much another person anyway. In a sense you're not reviewing your own code, you're letting it be reviewed by future you. But if you're in a team with multiple developers, having someone else review your code would be more efficient.
- _asummers 8y agoI tend to review my code with a reviewer hat, not with the author hat, before I open the PR. Find all the places where I'd call myself out for lazy names, poor abstractions, missing docs, etc. then go in and fix those. Repeat until satisfied, then open PR.
- rb808 8y ago> In practice it turns out that if I haven't touched code for months, reviewing it is almost the same as reviewing someone else's code, I really like this idea, haven't heard it before but it makes complete sense, thank you.
- rasjani 8y agoYellow rubber duck makes pair programming way more socially awkward ;)