Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment Re:Code Review Pair Programming (Score 1) 186

well, at Job 1 it was hit or miss, but at Job 2 we have a formal code review tool: https://www.reviewboard.org/

So yes, you do know who reviewed what, and whether or not they give their seal of approval.

now I'll admit that someone can just mark a review as fine without having read it, but as I said, nothing is perfect. Our process could certainly be improved more if we used a Github-style way of managing code (pull requests and all that) but since we use SVN and do all our work on the master branch it won't happen. I've fought for it but was the counter argument was that the team is not large enough to justify that kind of workflow. *shrug*

Comment Re:Code Review Pair Programming (Score 1) 186

> No, a review process is useless.

then

> You need actual code reviews for it to work,

I'm not sure what you're getting at.

The last two jobs I've done had a review process where all commits to the RCS resulted in a notification sent to the entire team, and was expected to be reviewed by two or more people.

One nice thing about this approach as well, better architecture. Not because of someone's review, but because the review process works far better when commits are small. Keeping commits small helped to improve modularity of our code, since 98% of the time we expect each commit to result in software that can be built (we did everything in our powers to avoid committing changes that would break a build).

Comment Code Review Pair Programming (Score 4, Interesting) 186

A proper peer review process is far superior. Review your plan with your teammates. If you're working with components that others work on, make sure they are part of the plan review. Once all questions are answered, put your headphones on and go forth and code. Rely on unit tests to catch the obvious problems, rely on integration tests to catch less than obvious problems, rely on QA to catch what your integration tests miss. Use linting, static code analysis, and other tools like Sonarqube to identify potential problems within your code that may not manifest themselves under day to day usage. Voila...

Is it perfect? Of course not. Will your software be 100% bug free? Of course not. It also doesn't solve problems related to lack of intelligence or experience amongst your teammates, and it doesn't solve problems related to lack of foresight from management who impose impossible deadlines or who close deals with customers that include features which don't exist. But the team will still be more productive than if they had to share computers and work in pairs. Programmers need focus and pair programming will ruin any focus you could have.

Comment Re:Can this entry be any more click bait? (Score 1) 100

> But lets get away from games and onto serious computing.

And games are not serious computing how? There are grand challenges that have been overcome in the technologies that power video games. Path finding, latency reduction, 3D computation, and so on.

Not to mention budgets that exceed that of some "enterprise" firms.

Comment what is their development strategy? (Score 2) 112

Every commit I make at work is required to have at least one peer review and its' recommended to have two and we are not selling security-related software.

I've never heard of this company, but this revelation speaks volumes to their poor development strategy. Maybe they fell in love with buzzwords like Agile or Waterfall or whatever without realizing that proper processes like peer reviews have nothing to do with these buzzwords. Either way, they can not be trusted for letting this happen. Either they do not review their own code on a regular basis, or parts of management are corrupt for letting this happen. Either way, probably time to stop doing business with them.

Slashdot Top Deals

One small step for man, one giant stumble for mankind.

Working...