4.3 如何做 code review

[EthanLin-TWer]

Code Review

• https://classroom.udacity.com/nanodegrees/nd050/parts/7d3f6620-dde2-4e15-829d-16ba0ff4aa0e
• https://classroom.udacity.com/nanodegrees/nd050/parts/a49136e1-cd4f-4d2f-8354-cbea2f28ca1b

总套路 - SPECS

• Simplify Code
• Practice Kindness
• Explain Why & with Examples
• Connect Learners
• Style Consistently

执行顺序

1. Read the ACs/Rubrics
2. Scan and Run
3. Line by line commentary

Simplify Code

套到重构的话来说，就是找寻坏味道。再建议使用对应的手法重构之，再推荐手法对应的步骤咯。这里，只找几种最经典的坏味道：

• 重复代码
• 过长的类、方法、函数：过长如何衡量？这里有个答案，表示行数不能作为标准，可以用是否只做了一件事：http://stackoverflow.com/questions/475675/when-is-a-function-too-long
• 可读性 - 重命名

Practice Kindness

该表扬就果断表扬。http://stackoverflow.com/help/be-nice

• awesome - 哪里好，例子呢
• suggestion - 哪里可改进，具体有什么问题，如何修改，更多资料如何找，可工作的代码在哪里找
• required - 为何是 required 的，去哪里找 single source of truth

Explain Why & with examples

Connect Learners

• https://discussions.udacity.com/t/connect-learners/16515

给学生资源，给他们更大的知识空间和境界。包含但不限于：

• Youtube Channels
• Twitter groups
• Good websites

Style Consistency

最好是使用某种 lint 工具，这样保证样式自始至终是一致的。

Review of Reviews

1. Relevance: focuses more on student's code, not Udacity's
2. Specificity
3. Explaination
4. Guidance: suggestion & required comments reveals a clear direction to students and are actionable
5. Accuracy: comments(awesome, suggestion, required) are align to rubrics
6. Completeness: don't understand
7. Communication: discuss, not judgement

[JimmyLv]

这个套路简直棒呆！我也发现了「尝试重构既有代码，是一种很好的熟悉代码的手段」，问题有二：

• 没测试（无比费劲，但是自从有了「一步切换」理论倒也不是那么没胆去做，via 重构之十六字心法｜洞见）
• 重构到妥协之处（有时候会觉得代码很烂忍不住骂 X，但在尝试重构几番过后才知晓原作者的妥协之处。）

[EthanLin-TWer]

这篇重构之十六字心法简直无敌，描述了在 IDE 支持很好的语言下如何透过思想体会重构精髓，在 IDE 支持不很好的语言上，如何安全地进行重构。

「妥协」这个事情，发现在你那天重构了一天然后一切都回去了以后，开始意识到了啊哈哈哈