《构建之法》第4.17相应思考

       第四章  两人合作

（一）. 引用原文：代码复审看什么？是不是把你的代码拿给别人看就行了？ 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

相应思考：社会对不同职业的工程师在职业操守或职业行为方面有不同的要求，职业操守反映了一个职业人员的品质和品德，不仅关系到个人名誉，更重要的是关系到个人的事业发展和职业生涯，任何机构都是不会对品德有缺陷的人委以重任的。

 ·在工作中获得的不属于公共范围的信息应予以保密

 ·在工作中编写的代码和文档应视为公司的财产

 ·不得有意破坏或窃取公司的文档资源和代码资源

 ·不得在程序中嵌入非法或不安全代码

·不使用非法或非合理渠道获得的软件

 ·在任何条件下不兼职从事与公司业务相关的事情

 ·不违背规定私自进入计算机系统

 ·任何情况下不泄漏公司商业秘密，更不得为获取私利而出卖商业秘密

 ·克尽职守，自觉维护所服务的组织的合法利益

软件世界是一个日新月异的世界，软件工程师应该在自己的整个职业生涯中，不仅要不断更新和完善自己的专业知识，而且还要不断提升自己的道德情操和职业操守的水平以及管理能力。