Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: PullRequest (YC S17) – On-Demand Code Review

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 68 posts

Launch HN: PullRequest (YC S17) – On-Demand Code Review

#1

Post by lyal »

Hi! I am Lyal Avery, founder of PullRequest (https://www.pullrequest.com) - we’re currently in the YC S17 batch. PullRequest is offering code review as a service.

We built PullRequest to help developers. After waiting several days for feedback on a pull request while a colleague was on vacation, I knew there had to be a way to improve this process. Our mission is to improve code quality and save time for dev teams. We combine static and linting tools with real on-demand reviewers to help augment your current code review process. Dev managers like extra coverage, but our real intent is to free up developers to make better software more efficiently

We’re onboarding experts across a lot of different languages for this reason. Sometimes teams might only have one person working within a given framework/language – it can be difficult to get objective feedback before shipping to production if you’re working on an island.

All reviewers sign NDAs to protect your IP. We start with surface level reviews – complying with framework or language standards, algorithmic work, performance or other questions. Since our reviewers continue working on the same projects, they will also gain context for deeper reviews.

Looking forward to hearing your thoughts and feedback!

Re: Launch HN: PullRequest (YC S17) – On-Demand Code Review

#2

Post by git-pull »

This looks like something that could catch on, especially if you're already compartmentalizing projects into libraries, that alleviates a lot of hesitation in sharing a codebase. It's good to see that NDA's are involved as a layer of protection.

There are things that a human can suggest that computers can't. Such as a refactoring suggestion.

Here are a few ideas:

- Consider adopting a standard like EditorConfig (http://editorconfig.org/) for reviewers to have compliant indentation out of the box

- For Enterprise packages: perhaps there can also be an opportunity to sub-contract out features and write tests?

- Consider experimenting internal CI tools (like as done in open source projects) to scan for obvious/low-hanging fruit automatically

- Scanning for / suggesting package updates

- Provide QA / audit for a large open source project for exposure

- Security auditing

Here are things that are good to hear:

- Static / Linting: things like vulture, flake8, etc. seem like a nice thing to stick to. It's good that these linters have configuration files to it

Re: Launch HN: PullRequest (YC S17) – On-Demand Code Review

#3

Post by lyal »

git-pull wrote: post #2

This looks like something that could catch on, especially if you're already compartmentalizing projects into libraries, that alleviates a lot of hesitation in sharing a codebase. It's good to see that NDA's are involved as a layer of protection. There are things that a human can suggest that computers can't. Such as a refactoring suggestion. Here are a few ideas: - Consider adopting a standard like EditorConfig ( htt…

Thanks much! A lot of good notes; some initial reactions:

Completely agree re: editorconfig. Very necessary to prevent bikeshedding. We're actually building a dedicated review IDE.

Part of our roadmap is to offer open source projects code review -- not just for exposure, but to work with reviewer standards on.

We're definitely interested in security review.

Re: Launch HN: PullRequest (YC S17) – On-Demand Code Review

#4

Post by traviswingo »

Seems like a good idea, but I wonder about the true quality of the review? In my experience, only a true team member who's familiar with the project (i.e. has actually been working on it) can provide a quality code review. Beyond that, they're just looking at ways to optimize blocks or find weird bugs in non-breaking recursive lines...

Re: Launch HN: PullRequest (YC S17) – On-Demand Code Review

#6

Post by lyal »

traviswingo wrote: post #4

Seems like a good idea, but I wonder about the true quality of the review? In my experience, only a true team member who's familiar with the project (i.e. has actually been working on it) can provide a quality code review. Beyond that, they're just looking at ways to optimize blocks or find weird bugs in non-breaking recursive lines...

Great insight. Definitely something we are tackling. For once off reviews on an individual pull request, it can be challenging to do anything but surface review. As a result, we're building some summarization tools to help provide context rapidly to a reviewer. Over the lifetime of a project, we have reviewers assigned to the same projects so that they build up context, in the same way that team members do.

Re: Launch HN: PullRequest (YC S17) – On-Demand Code Review

#7

Post by lyal »

acconrad wrote: post #5

Awesome idea, just signed up to help out and review code! Is there an incentive / gamification system to reward strong reviewers so their reputation increases as they provide good feedback to companies?

Thanks! We're still early in our life cycle -- but on the roadmap is the creation of reviewer profiles (as an optional feature). This'll allow us to highlight strong reviewers, their projects, etc.

Incentives and gamification are definitely there as well. We want to bonus people for doing thoughtful code review.

Re: Launch HN: PullRequest (YC S17) – On-Demand Code Review

#8

Post by danpalmer »

Roughly speaking, I think there are 3 aims for code review:

1. Style/consistency, re-use of existing code, utils, etc.

2. Architecture/design, how does this fit into the rest of the codebase, scaling concerns, how will the deploy work, will this have race conditions, etc.

3. Knowledge sharing with other members of the team.

Currently, it looks like this would satisfy half each of 1 and 2, but will miss the (possibly large) amount of context that people working on the project have. To be honest, I don't know how you solve that. How does a reviewer who lacks knowledge about the codebase spot a common pattern and know that another dev abstracted that out into a util a few weeks ago, for example.

I also wonder what could be done to address (3). I've seen the team I work on go from a place where everyone could review everything to a place where I can't review all the code that goes live, and particularly after time off, I can't really catch up. I'd love to see some sort of automated changelog of useful notes on what has changed. I'm not sure if this is possible, but summarising merged PRs, highlighting config changes, showing new utilities that have been added, etc, would be quite valuable.

Re: Launch HN: PullRequest (YC S17) – On-Demand Code Review

#9

Post by lyal »

danpalmer wrote: post #8

Roughly speaking, I think there are 3 aims for code review: 1. Style/consistency, re-use of existing code, utils, etc. 2. Architecture/design, how does this fit into the rest of the codebase, scaling concerns, how will the deploy work, will this have race conditions, etc. 3. Knowledge sharing with other members of the team. Currently, it looks like this would satisfy half each of 1 and 2, but will miss the (possibly…

Thanks - excellent notes regarding knowledge sharing. We've kicked around the notion of automatically generating reports from reviews for sharing around the contents of the code review (and underlying changes).

Could be fascinating to highlight config/code/approach changes on each pull request. Could actually help velocity across entire teams.

Re: Launch HN: PullRequest (YC S17) – On-Demand Code Review

#10

Post by jbrooksuk »

danpalmer wrote: post #8

Roughly speaking, I think there are 3 aims for code review: 1. Style/consistency, re-use of existing code, utils, etc. 2. Architecture/design, how does this fit into the rest of the codebase, scaling concerns, how will the deploy work, will this have race conditions, etc. 3. Knowledge sharing with other members of the team. Currently, it looks like this would satisfy half each of 1 and 2, but will miss the (possibly…

To me, code style should not be part of the review process. This should be automated away https://blog.alt-three.com/code-reviews-are-not-about-coding...
Post reply on HN