##// END OF EJS Templates
http-proto: in case incoming requests come in as chunked stream the data to VCSServer....
http-proto: in case incoming requests come in as chunked stream the data to VCSServer. This should solve a problem of uploading large files to rhodecode. In case of git with small postBuffers GIT client streams data to the server. In such case we want to stream the data back again to vcsserver without reading it fully inside RhodeCode.

File last commit:

r1:854a839a default
r1423:8b2e03e1 default
Show More
reviewing-best-practices.rst
20 lines | 1.0 KiB | text/x-rst | RstLexer
/ docs / code-review / reviewing-best-practices.rst

Code Review - Best Practices

The following is a list of best practices for reviewing code gathered from various sources:

  • Implement a Core Review standard, because the yield of the Code Review phase is 50 to 80% better than that of the Test phase.
  • Review between 100 and 300 lines of code at a time and spend 30-60 minutes doing it for best results.
  • Avoid code review meetings, because meetings contributed only 4% of the defects found in the code inspections.
  • Slow down to a comfortable pace, as reviewers slower than 400 lines per hour are above average in their ability to uncover defects. But when faster than 450 lines/hour the defect density is below average in 87% of the cases.
  • Take a time-out, because defects are found at relatively constant rates through the first 60 minutes of inspection. At that point the checklist-style review levels off sharply; the other review styles level off slightly later. In no case is a defect discovered after 90 minutes.