A service like this would only be able to find a certain class of issue. Basically syntax, but not semantics. There is no substitute for deep knowledge of a particular codebase.
Code Review as a Service
61–70 of 238 posts
Re: Code Review as a Service
#62I'm all for this if the person reviewing my code will know the context, history and all the details and conversations we had as a team. But in order for that to work, I'd probably be taking most of this reviewer's time. And obviously in order for them to get up to speed with our practices, conventions, architecture, code style and whatnot, they'd probably need to start by doing a whole lot of development on our proje…
While I agree in general, some forms of code reviewing require less context than others. They say "We review within your tools to catch security threats, stop crashes, and fix performance issues before they reach production.", and it does seem to me that these things are less a matter of style/context than just noticing potential issues. Not sure though, I had the exact same thoughts as you when first seeing this. Ed…
Code the falls between between "I need an experienced team member to see the issue" and "A few static analysis tools would no doubt have seen it" must be vanishingly small.
For specific areas, I can see myself paying for external code review. For example some open source library authors sell it as a service, so they can review the specific parts of the code where the library is used. Rob Menschings FireGiant is one such example.
Security reviews (Audits) I can also see a good use for. The current practice here is already to have external non-domain-experts review the code. So making that simpler or more frequent is a net win. The reviews I see little use for would be normal feature code, (pull request reviews) which need a lot of context and domain knowledge to even begin to review.
Not audits, or reviews of specific areas or aspects of the code.
Re: Code Review as a Service
#63Earlier quoted context omitted.
> Reviewers earn anywhere between $50 and over $3,000/week. They are operating just like a freelancing platform, right? How many hours is a "week" for them? 40 hours? > PullRequest’s payment rates are comparable to those of a senior-level engineer based in the US. Like include life and health insurance, paid vacation, profit-sharing, a generous signing bonus, and more?
Why don't you say what you're thinking instead of disguising your opinions as questions?
Let me try: This looks way too cheap to be able to afford good enough reviewers to be worth using; if someone is good enough to be able to pick up a new codebase and usefully review changes that quickly, they'd get a better paying job.
Re: Code Review as a Service
#64This entirely misses the point of code review. Say it with me: Code review is a knowledge transfer exercise. Finding bugs, security vulnerabilities, and keeping the code maintainable are merely side effects that we appreciate along the way. The primary purpose of code review is increasing the bus factor of the given piece of code and facilitating organic knowledge transfer. That's it.
I mentioned this idea to a very knowledgeable enterprise architect. I was mentioning how much I'd enjoyed being able to use the code review process in this way. His reply: As good of an idea that is, it breaks Agile. So long as the code meets the biz-provided spec, it must be accepted, and if there are other concerns with the code, to make a tech debt ticket to address it at a later date. This, of course, horrified m…
Anyone with Architect in their title receives skepticism from me. I've turned down title changes that include it and I refuse to put it on my LinkedIn.
Re: Code Review as a Service
#65I wish person (people) involved in making this would do some more research, it's completely missing a point of PR review.
This is to me a set of linters with human error involved..
Re: Code Review as a Service
#66I'm all for this if the person reviewing my code will know the context, history and all the details and conversations we had as a team. But in order for that to work, I'd probably be taking most of this reviewer's time. And obviously in order for them to get up to speed with our practices, conventions, architecture, code style and whatnot, they'd probably need to start by doing a whole lot of development on our proje…
Code should be written to be understood without that context. If comments and documentation aren’t enough context for the code to be understood, it probably isn’t written very well.
Re: Code Review as a Service
#67Earlier quoted context omitted.
But almost any good SA can catch all of those issues, a person doesn't need to look through the code for that.
This is very close to saying Halting problem is not, in fact, a problem: https://brilliant.org/wiki/halting-problem/
Not at all, it is saying that if the only things this service is providing is a human doing SA (since they dont have any deep-knowledge of the codebase), then you could just use an SA.
Code review in the real world misses the Halting problem, the only way you can really see it is if you know the codebase well enough to SEE it, and any 3rd party that is given a pull request to complete in a timely manner will not have time to fully learn your code base or even the modules you are submitting.
Re: Code Review as a Service
#68This entirely misses the point of code review. Say it with me: Code review is a knowledge transfer exercise. Finding bugs, security vulnerabilities, and keeping the code maintainable are merely side effects that we appreciate along the way. The primary purpose of code review is increasing the bus factor of the given piece of code and facilitating organic knowledge transfer. That's it.
I mentioned this idea to a very knowledgeable enterprise architect. I was mentioning how much I'd enjoyed being able to use the code review process in this way. His reply: As good of an idea that is, it breaks Agile. So long as the code meets the biz-provided spec, it must be accepted, and if there are other concerns with the code, to make a tech debt ticket to address it at a later date. This, of course, horrified m…
His logic would apply to tests of all sorts. As long as the dev says the feature is done, that’s the end. And he’s wrong. As teams (or companies, or whatever unit) we get to decide our definition of “Done”. I suggest that definition include appropriate testing. And appropriate code review, which serves two purposes… catching defects and knowledge sharing.
Re: Code Review as a Service
#69I'm currently the only developer in my startup and I crave for high quality feedback, so this service sounds like it's a gift sent from heaven – especially for the $699 price tag per month. I guess they probably make a mixed calculation: take a small company with 10 devs. Two of them are part-time, on any given week one of them is on holidays/sick leave, one is very junior and doesn't contribute much yet, another one is more concerned with project management than with writing code and one has in fact transitioned into management but remains on the dev team because it's part of their identity to still "get their hands dirty" (even though they don't have the time to produce much code) – so you might end up with sth like 4-7x more code than I write, but 10x the payments. My productivity is not above average, but I have very little overhead besides coding.
Unfortunately, I cannot find any information about a minimum team size for the PRO plan. I think I'll give them a try.
Re: Code Review as a Service
#70I'm all for this if the person reviewing my code will know the context, history and all the details and conversations we had as a team. But in order for that to work, I'd probably be taking most of this reviewer's time. And obviously in order for them to get up to speed with our practices, conventions, architecture, code style and whatnot, they'd probably need to start by doing a whole lot of development on our proje…
Disclaimer, I'm the CTO @ PullRequest.
One thing to note about our service is that we are not trying to replace your code review process if it is already working well and we strongly agree that knowledge transfer is a very important part of code review. ( We actually have code review metrics as well that help encourage and reward your internal code review process. ) However what we do believe and see on a daily basis is degree that we help supplement the process and help catch many issues as well as inject a unique perspective. Our reviewers are all highly qualified, many are maintainers of popular open source projects or work at top tech companies. Our reviewers also gain context over time similar to a new senior engineer on your team. Reviewers also can share notes with each other to build up a corpus of information for your project over time.