--- title: "#22.7 TBD 讀網站會 - Continuous Review" tags: Meetups date: 2022-07-14 --- [Link](https://trunkbaseddevelopment.com/continuous-review/) # Continuous Code Review ## The high bar today 今天的標準 Continuous Code Review is where the team commits to processing proposed commits (to trunk) from teammates' trunk speedily. 持續地程式碼審核是團隊致力於快速處理來自團隊內的隊友提交到Trunk上時需要進行審核的行為. The idea is that a system (the code portal probably) allows developers to package up commits for code review and get that in front of peers quickly. And that peer developers make a commitment to do code reviews objectively and quickly. 這想法是一個系統用來允許開發人員能打包提交用來進行程式碼審核並且迅速地呈現在團隊面前. 且團隊間(同行們)承諾以客觀、迅速地進行程式碼審核. There is a cost to multi-tasking, so maybe someone in the dev team who is between work items at that moment should focus on the review before they start new work. With a continuous review ethos, it is critical that code reviews are not allowed to back up. 多個任務的處理是有成本要承擔的,也許開發團隊的成員正處於項目中或者某些開發者在進行新的任務前都應該專注於程式碼審查. 這關鍵是程式碼審查者不該允許先往更後面的PR去做審查. Companies doing Extreme Programming, often allow that pair of eyes to count as a review. Some companies require multiple reviews of code. For “the pair as reviewers too” scenario, one might have been enough and that commit will land in the trunk, without others looking at it. Five minutes and 20 seconds into Guido van Rossum’s famous 2006 Mondrian presentation, he states “code review is a best alternative to pair programming”, and that it is “basically asynchronous pair-programming”. 有在進行極限編程的公司, 經常用眼睛進行審查. 有些公司需要對程式碼進行很多次的審查. 進行Pair Programming的夥伴, 也是一種reviewer. 主要是其他人不應該在別人還沒看過它之前, 就讓程式碼流入Trunk. 程式碼審查也算是一種Pair Programming, 這算是一種非同步的Pair. ### Pull Requests (PRs) The pull-request (PR) model introduced by GitHub is the dominant code review model today. The concept was available from GitHub’s launch in 2008 and has revolutionized both open source and enterprise software development. Google were secretly doing the same thing with custom tooling around their Perforce install from about 2005, and Guido’s presentation on Mondrian in 2006 (as mentioned) leaked that to the world (see below). PR模型是Github引進的. A PR is one or more commits towards a goal described in an accompanying piece of text. The act of creating the PR from the branch signals the end (or a pause) in work, and the wish for the reviewers to get busy (and the CI daemon to wake up and build/verify the branch). There are caveats though. PR有1個或多個commits來完成一個目標, 並且伴隨著一段文字的敘述. #### Open Source contributions via PRs These can come from anyone who has an account on GitHub (or equivalent). They will have forked your repository and the PR will be about commits that would come back to your repository. They may delete their repository after you consume their commits. If these are unsolicited you may well take your time reviewing them. Indeed you may never consume them, if you don’t like them. Hardly continuous, but open source is mostly a volunteer activity. #### PRs from colleagues Regardless of branching model, the wish is for the PR to be reviewed fairly quickly. On GitHub (and possibly others) the PR can come from a fork or a branch in the main repo. There is little difference to the processing of these. In Trunk-Based Development teams, the PR should be on a [short-lived feature branch](https://trunkbaseddevelopment.com/short-lived-feature-branches/) and processed very quickly by reviews towards merging back to trunk/master. A few minutes for the review is best, and tens of minutes acceptable. More than a hour or two, and you are negatively affecting cycle times. The short-lived feature branch may have received many commits before the developer initiated the pull request. Some developers will squash (rebase) the changes into a single commit before starting code review. Some teams have a policy in favor of or against squash/rebase. 來自同事的PR 不管分支模型, 都會希望PR很快的被審查. 在Github上, PR可以來自fork或branch. 這兩者幾乎沒太大差異. 在TBD團隊中, PR應該在一個短生命週期的分支上, 並且盡快的被審查然後合併到trunk. 幾分鐘最棒, 幾十分鐘也能, 但希望別拖到幾小時以上. 短生命週期分支也許會有很多開發者之前提交的提交. 一些開發人員會在PR前將提交給壓縮或rebase. > Common Code Owners > > Commits being reviewed are never rejected for “Only I am allowed to change source in this package” reasons. Rejections must be for objective and published reasons. 要公平阿!! # Enterprise code review - as it was In enterprises, if code review was done at all prior to 2008, it was done in a batch, and probably a group activity. It was often abhorred as it gave a lead developer/architect a moment to set an agenda, round on a large portion of the attendees and make sure that their own code flubs were not discussed at all. Historically, open source teams never had the luxury of procrastinating about code review. They either did code reviews as they went (perhaps days were the review cadence, not hours or minutes), or they did not bother at all. # See also See Game Changers - Google’s Mondrian and Game Changers - [GitHub’s Pull Requests](https://trunkbaseddevelopment.com/game-changers/index.html#github-s-entire-platform-2008-onwards) for the industry impact of continuous code review.