构建之法读后感

Posted 2021-06-20 暖旧

代码复审

代码复审会有核查表，我们可以通过核查表来学习代码复审。
一方面是作为复审者，该审查代码的哪些方面；另一方面自己写的程序也需要自我复审，自己写完程序后，对照着核查表进行核查，不断思考总结提高编码水平。

一. 概要部分
1. 代码符合需求和规格说明吗？
2. 代码设计是否考虑周全？
3. 代码的可读性如何？
4. 代码容易维护吗？
5. 代码的每一步都执行并检查过了吗？

二、设计规范部分
1. 设计是否遵从已知的设计模式或项目中常用的模式？
2. 有没有硬编码？
3. 代码有没有依赖某个平台？移植性差？
4. 开发者新写的代码是否能用已有的库函数实现？或者是否已经存在类似的功能可以直接调用？
5. 有没有无用的代码可以清除？（程序中可能有很多被注释掉的代码）

三、代码规范部分
修改的部分符合代码标准和风格？或者符合已有的团队代码规范？

四、具体代码部分
1. 有没有对错误进行处理？ 对于调用的外部函数，是否检查了返回值或处理了异常？
2. 参数传递有无错误？
3. 边界条件是如何处理的？switch语句中的default分支是如何处理的？循环中有没有可能出现死循环？
4. 是否存在资源泄漏的可能？（内存、文件、数据库访问资源等等）
5. 数据结构中有没有用不到的元素？

五、效能
1. 代码的效能如何？最坏的情况是怎样的？
2. 代码中，循环的部分是否有可优化的部分？比如 String用StringBuilder来进行修改
3. 对于系统和网络的调用是否会超时？如何处理？

六、可测试性
代码是否需要更新测试用例或创建新的单元测试？

如何影响别人

反馈的技巧

团队中，需要成员之间进行很多反馈，比如表达感谢、阐明要求或指出不足等等。如何进行有效的反馈呢？

书中介绍了评论别人的三种层次。

最外层：行为和结果
中间层：习惯和动机
最内层：本质和固有属性

书中的例子讲解的很清楚，这里摘抄一下，便于没有读过原文的朋友理解这个技巧。

• 王村的程序员果冻邀请邻村的姑娘小丽去听音乐会，但是果冻却迟到了，针对不同的层次，小丽会给出不同的反馈。
  
  • 最外层：行为和结果 果冻你迟到了，让我很着急，我们现在进不了会场，错过了精彩的第一幕表演。
  • 中间层：习惯和动机 果冻你又放我鸽子，你总是不重视我，让我等在外面，让我丢人！
  • 最内层：本质和固有属性 果冻 你太自私了，心理都没有别人！你们男人没有一个好东西！

在技术团队中，我们的反馈还是要着重于行为和结果，不要贸然深入到习惯和动机、本质。除非情况非常严峻，需要触动别人内心深处，让别人悬崖勒马。

理论学习了，具体实践中，还可以使用三明治反馈法，实现别人容易接受的反馈。

三明治有两块面包一块肉。
在表达观点时，先使用第一片面包：强调双方的共同点。团队共同的愿景，让对方处于一个安全的环境。
接着把建设性的意见加工成肉片：强调过去你做的不够，不过以后可以做的更好。
最后再来一片面包，呼应开头，鼓励对方把工作做好。

关于代码规范，对于不同团队来说，可能会有不同的规范框架，需要结合实际工作，在实际工作中时刻注意代码规范的问题。