第四章 两人合作
（一）. 引用原文：代码复审看什么？是不是把你的代码拿给别人看就行了？ P72
相应思考：代码复审的正确定义：看代码是否在代码规范的框架内正确的解决了问题。如果花几秒钟去搜索有关内容，你会发现许多论述代码审查好处的文章，你还会发现许多介绍如何使用代码审查工具的文档，但能够在你审查他人代码时指导查什么的内容却很少见，或许没有明确审查条目的原因是：有太多不同的因素需要考虑，就像对任何（功能性或非功能性）需求，个体组织对各个方面的优先级都有不同的考虑。以下为百度到的常见代码复审步骤：
（1）设计
·新代码是否与整体架构匹配？
·新代码采用哪些设计模式？这些模式合适吗？
·代码是否处于正确的位置？例如，如果代码执行与顺序有关，它是否能按顺序执行？
·新代码能否复用部分已存在代码？新代码能否给已存在代码提供复用部分？
·代码是否超出设计标准？这种复用构造现在是不是不需要？团队如何根据YAGNI权衡复用？
·可读性与可维护性
（2）命名（字段、变量、参数、函数以及类）
·能否反映它们代表的事物？
·通过阅读代码，我能否理解代码的目的？
·测试是否覆盖了绝大部分情况？是否覆盖常见情况和异常情况？是否存在没考虑到的情况？
·难以理解的代码段是否进行了备注、评论或者使用易懂的测试案例进行覆盖（符合团队的偏好）？
（3）功能
·代码的实际工作是否符合预期？如果有自动化测试来确保代码的正确，测试能否测出代码满足约定要求？
·代码看上去是否含有细微错误，比如使用错误变量进行检查，或者把 or 误用为 and？
（4）你是否考虑过……？
·代码中是否存在潜在的安全问题？
·是否需要满足规范要求？
·对于没有覆盖自动化性能测试的代码段，新代码是否引入了不可避免的性能问题，比如不必要的数据调用或远程服务？
·作者是否需要创建公共文档，或者修改现有的帮助文档。
·展示给用户的消息是否检查无误？
·是否存在导致产品崩溃的明显错误？代码是否会意外指向测试数据库，或者是否有应该替换成真正服务的硬编码存根代码？
参见：https://blog.csdn.net/cindy_cheng/article/details/78571034
（二）.引用原文：比较通用的，也是经过很多实践检验的方法叫做“匈牙利命名法”，匈牙利命名法是什么？ p66
相应思考：匈牙利命名法是一种编程时的命名规范。基本原则是：变量名=属性+类型+对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分，要基于容易记忆容易理解的原则，保证名字的连贯性是非常重要的。部分举例：
·hwnd ： h 是类型描述，表示句柄， wnd 是变量对象描述，表示窗口，所以 hwnd 表示窗口句柄
·pfnEatApple ： pfn 是类型描述，表示指向函数的指针， EatApple 是变量对象描述，所以它表示指向 EatApple 函数的函数指针变量
·g_cch ： g_ 是属性描述，表示全局变量，c 和 ch 分别是计数类型和字符类型，一起表示变量类型，这里忽略了对象描述，所以它表示一个对字符进行计数的全局变量
参见：
第十七章 人，绩效和职业道德
（三）引用原文：软件工程师的职业道德 p405
相应思考：社会对不同职业的工程师在职业操守或职业行为方面有不同的要求，职业操守反映了一个职业人员的品质和品德，不仅关系到个人名誉，更重要的是关系到个人的事业发展和职业生涯，任何机构都是不会对品德有缺陷的人委以重任的。
·在工作中获得的不属于公共范围的信息应予以保密
·在工作中编写的代码和文档应视为公司的财产
·不得有意破坏或窃取公司的文档资源和代码资源
·不得在程序中嵌入非法或不安全代码
