Hacker News Reader

Comment by dankohn1 | Hacker News Reader

There's this magical process called continuous integration that internalizes the impact of bad (or, more likely, misguided) developers. Don't let them merge their branch until all tests pass. If their commit breaks something while all tests still pass, then direct them to write the missing tests.

View on HN

CI does nothing to prevent bad developers checking in bad code. You just end up with equally poor unit tests.

If it doesn't "prevent" people from checking in code (in the strictest sense of the term) that breaks lots of other code, it certainly does some combination of slowing them way down, notifying other people way sooner, or forcing them to be a great deal more skilled in how they check in their breaking code (in the "if you make something idiot-proof, someone will build a better idiot" sense of skilled).

It's not perfect, but it's better than most of the alternatives, and perfect isn't actually on the table anyhow.

True. Code reviews and standards are the tools to use in this case.

I've found that code reviews are one of the best ways to increase code quality. Even just talking with other developers about why they've done things is helpful in thinking about simpler options and keeping things closer to the architectural vision.

Just questioning the implementation is enough to improve quality. Plus it helps people grow without putting them on the spot (if done right).

Who cares about poor unit tests in this case? It's all about the INTEGRATION tests that run on CI to make sure your bad developer can only fuck their shit up and not anyone else's. And if you have bad developers building your integration testing framework, you have bigger problems.

If someone checks in code that breaks a bunch of tests, then you know right away. And the underlying assumption is that tests are written by multiple people with varying degrees of quality. Can bad code sneak through the tests? Of course! But to say it does no good at all is wrong.

Sometimes they are in politically privileged positions and you can't get rid of them, ask me how I know.

How do you ... know?

Agreed. The article mentions influential developers like this who are stuck in the past.

Because you are one ?

One of our (now ex) developers would write tests that setup a mock, and test the properties of the mock, so if you deleted the source code, the test would still pass!

His pull requests sucked up hours of other devs time, but bad stuff still leaked through simply because the other devs didn't have time to rewrite his PR. He was fired eventually, but the ongoing cleanup still continues...

Reply on news.ycombinator.com