diff options
author | Hui Lan <lanhui@zjnu.edu.cn> | 2019-05-07 08:53:07 +0800 |
---|---|---|
committer | Hui Lan <lanhui@zjnu.edu.cn> | 2019-05-07 08:53:07 +0800 |
commit | 056c1a3f58f1fb628ae8ff343dc1846f540f6b2e (patch) | |
tree | 261bef25d180248e954b84fd3a483fd659320f8b /spm-slides.tex | |
parent | 61468836c97a5b235a28f8d7ddca68e87159f5d1 (diff) |
Make Code Review a separate slide as it is important. Add more stuff for Code Review
Diffstat (limited to 'spm-slides.tex')
-rw-r--r-- | spm-slides.tex | 48 |
1 files changed, 41 insertions, 7 deletions
diff --git a/spm-slides.tex b/spm-slides.tex index 66d2e31..0ec3a9b 100644 --- a/spm-slides.tex +++ b/spm-slides.tex @@ -797,7 +797,7 @@ Project stability depends on: Healthy turnover won't damage social norms because we have regular {\em transmission effort}. -Children's songs survive for centuries. {\em Greensleeves} (the 16th-century folk tune). +Children's songs survive for centuries. {\em What child is this (1865)? Greensleeves} (the 16th-century folk tune). {\em Classic of Poetry} (China's Book of Songs from 1046–771 BC). @@ -821,14 +821,48 @@ or private, from someone that they behaved inappropriately. \url{https://www.contributor-covenant.org/version/1/4/code-of-conduct} -{\bf Code review}. IMPORTANT. Peer review in the open source world. -Result - software quality. People do their best work when they know -that others will take the time to evaluate it. +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Code review} + +Do commit review, code review regularly. + +Look at other people's code {\em changes} as they arrive. + +Look for bugs and areas of posssible improvement. Thing we could +catch: memory leaks, off-by-one errors, insufficient comments, +insufficient API documentation, security vulnerabilities, compliments +... + -One could contribute as much to the project by reviewing others' -changes as by writing new code. +{\bf Important} to have more eyeballs. + +This is {\em peer review} in the open source world. + +Why focus on reviewing recent changes? + +\begin{itemize} +\item It works better socially. Timely feedback for fresh changes. A great way to interact with people. Confirm that what they do {\em matters} (is seen and understood). People do their best work when they know that others will take the +time to evaluate it. +\item The recent change is a good starter for getting familiar with the codebase. Also look at the affected callers and callees. +\end{itemize} + +Result - better software quality. + +The review should be public, so that other people can see it and know that a review has happened, and is expected. + +Commit notifications are useful. + +A valuable way to spend time. One could contribute as much to the +project by reviewing others' changes as by writing new code. + +Case study. Greg Stein reviewed every line of every single commit +that went into the code repository, and never complained about being +the single reviewer. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Technical debt} -Memory leaks, off-by-one errors, insufficient comments, security vulnerabilities, compliments ... +tbd %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Be open from day one} |