Live data from Hacker News

Code Review as a Service

pullrequest.com

111–120 of 238 posts

Re: Code Review as a Service

#111

On top of what others have already flagged this is a big no for any companies security & compliance. Why would any company share their private codebase ?

Disclaimer: I'm Dan Mateer, COO at PullRequest

Great question; security and compliance is a very big consideration for our customers. All code review on PullRequest is done within the platform, engineers in the PullRequest network cannot clone branches like in a garden variety source control, and we have a number of tools to give clients as much control as possible as to what our platform and engineers in our network are exposed to (e.g., https://docs.pullrequest.com/pullrequest-docs/code-review-se...).

We work very closely with our customers to ensure configurations are set up to provide our engineers with adequate context while limiting or outright restricting exposure of things they want private private.

This is also a big part of why PullRequest Reviewers are by and large restricted to US-based engineers. This ensures accuracy and consistency of criminal background checks and ease of enforceability for our non-disclosure agreements. From a legal risk assessment perspective, using PullRequest is similar to hiring a technical consultant.

Re: Code Review as a Service

#114

Having on-demand engineers look at code, without broader context on the project it is in my view the same as something that can be automated either or both via static analysis and custom ci/cd workflow checks. This can probably makes sense on a project with more junior engineers where many basic improvements can be supposedly suggested without needing broader context? I would be keen on hearing the use case

I can think of one real-world use-case, though I have never used this product.

It's pretty common in larger companies to have legacy products with a couple of very senior (usually overworked) people and a larger number of junior people. The juniors very often have little experience with the language, much less the frameworks, of these legacy systems. So PR's from junior devs are often very frustrating for senior devs (wrong language conventions, not how AWS is done, paradigm misunderstandings, inaccurate comments) -- and the perverse incentives resulting from that are pretty obvious. Bad code ships.

If passing "code review as a service" were a requirement before the juniors could put up changes for seniors to review, in my experience that would be money well spent.

Re: Code Review as a Service

#115

I'm imagining that to make such service profitable, offering something like $699 per developer per month, you are not hiring reviewers from USA, right?

For many of us who work for pullrequest.com, it's a side gig. Some are full-time, but I have a day job. I like to do 1-2 PRs per day, and it pays for my iPhone and MacBook habit.

Re: Code Review as a Service

#116
post #61

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.

A really cool side effect of working with pullrequest.com over the past year is that I do feel that I've gotten to know some of these projects. Some interactions end up becoming lengthy conversations between the reviewers and the engineering teams over the course of multiple pull requests. We point out potential issues and are still around when those issues are addressed. For some projects, the reviewers are treated like part of the team.

Re: Code Review as a Service

#117

This implies that you have no-one in your team to do code reviews and that you're fine allowing random third parties access to your infrastructure and a peek into your projects and code base... Both the premise and the proposed solution sound very odd to me.

Most projects I have reviewed for pullrequest.com have reviewers on the engineering team also. In a way, we are helping them get better at reviewing their own code. I imagine that some teams won't need us after a while. On the other hand, in some projects we have become trusted members of their teams.

Re: Code Review as a Service

#118

This 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.

This. Code review is a terrible way to find bugs... At best you'll get the more Senior reviewer to spot library uses that are known to be workable but problematic (eg poor performance), coming from their experience. But straight up logic bugs are hard to spot.

The big thing that code review achieves is that it ensures a 2nd person understands the code that was written, and therefore it is possible for the reader to understand.

So 3 years down the road and you're looking at some counterintuitive piece of code, the reader isn't wondering *why on earth did he write it like this? Is it working around some cryptic edge-case bug in the framework or were they just stupid?"

Re: Code Review as a Service

#119
post #83

Except I don't believe in code reviews. Over the years I have experimented with pair programming and I think it is way better solution. The one catch with pair programming is that some people just prefer to work alone and it is really draining to be talking constantly for couple of hours. I have modified the system to do on/off pair programming (ie. split up a little bit of work, rejoin later in the day, share what w…

I agree with your points, but the pair programming also has downsides, main one being that it doubles the total cost per task, and also it's usually limited to 2 pairs of eyes (again because of the cost), while code reviews can (and should) be done by as many members of the team as possible.

Re: Code Review as a Service

#120

I have performed reviews on pullrequest.com, and lack of context tends not to be an issue. Code review is an interactive process, where questions can be posed to the PR authors, and PR reviewers have access to search the codebase. Customer success at pullrequest.com also provide context for the repo and organization working practices, attached at the top of PR descriptions, to help reviewers with context and to know…

> Code review is an interactive process, where questions can be posed to the PR authors, and PR reviewers have access to search the codebase.

I also performed reviews on pullrequest.com (~2+ years ago?). I firmly believe code reviews are an interactive and knowledge sharing process but was explicitly told NOT to ask questions during pull requests, but instead to make statements focusing on bugs and style.

Based on the comments here, this def looks valuable to some of pullrequests.com customers. I believe this is more of a human acting as a safety net, or risk mitigation strategy, and loses the majority of the value that pull requests can provide to an organization.

Post reply on HN