So I’m pretty new to the field. I just finished a year at my first gig at a software job. I don’t have a lot of experience, but I think our company has some pretty bad practices. Namely, we don’t...
So I’m pretty new to the field. I just finished a year at my first gig at a software job. I don’t have a lot of experience, but I think our company has some pretty bad practices. Namely, we don’t do code reviews or write unit tests. Would you guys consider code reviews an industry standard? Are there a lot of benefits to using them or are they not that useful?
The rationale in the first section of the article about code reviews being a way to ensure continually increasing code quality rather than continually degrading is a good way to look at it. I've...
The rationale in the first section of the article about code reviews being a way to ensure continually increasing code quality rather than continually degrading is a good way to look at it. I've found that a definite advantage, both from the simple benefit of a fresh pair of eyes with a new perspective, and from the fact that it's harder to be lazy and fall into bad practice when you know you'll have to justify it to your colleagues!
I also see a second major benefit to code review: it means that there are always at least two people who understand any given change. Anything that's clear to the author but not the rest of the world gets caught and explained while it's fresh in their mind. It's far easier to work on someone else's code six months down the line if you both looked through and discussed it close to when it was written - and the advantages of having the reviewer there if the author leaves the company, or is just on holiday when an issue comes up that touches their code, are pretty clear.
As to unit tests, they're an important tool in the arsenal and you should definitely be using them. Having them is almost always better than not having them, and they provide a significant reassurance that new code hasn't broken old functionality. However, they aren't infallible - 100% coverage does not mean 100% bug free, and I've run across more than a few developers who don't want to hear that.
So I’m pretty new to the field. I just finished a year at my first gig at a software job. I don’t have a lot of experience, but I think our company has some pretty bad practices. Namely, we don’t do code reviews or write unit tests. Would you guys consider code reviews an industry standard? Are there a lot of benefits to using them or are they not that useful?
The rationale in the first section of the article about code reviews being a way to ensure continually increasing code quality rather than continually degrading is a good way to look at it. I've found that a definite advantage, both from the simple benefit of a fresh pair of eyes with a new perspective, and from the fact that it's harder to be lazy and fall into bad practice when you know you'll have to justify it to your colleagues!
I also see a second major benefit to code review: it means that there are always at least two people who understand any given change. Anything that's clear to the author but not the rest of the world gets caught and explained while it's fresh in their mind. It's far easier to work on someone else's code six months down the line if you both looked through and discussed it close to when it was written - and the advantages of having the reviewer there if the author leaves the company, or is just on holiday when an issue comes up that touches their code, are pretty clear.
As to unit tests, they're an important tool in the arsenal and you should definitely be using them. Having them is almost always better than not having them, and they provide a significant reassurance that new code hasn't broken old functionality. However, they aren't infallible - 100% coverage does not mean 100% bug free, and I've run across more than a few developers who don't want to hear that.