Code Review回顾---Avoid potential risk.

Code review碎碎念。


前几天进行team code review的时候又出现了一些有趣的点子，写下来记录一下也为了以后回顾。这次的topic是"Avoid potential risk"。

这个点子结合前几天看到的一个科普文：
有哪些外行人看来很蠢的设计实际上却是精妙无比？

一直有个想法，Software Engineer跟工业界的建筑设计，机械设计有一定的共同性。比如盖一房子，一层的砖瓦房请一些普通的工人就可以完成。但是如果想盖起来8-10层的居民楼，就需要专业的施工、设计团队，完成各种部分。如果想建造超过30层的摩天大楼，那么需要更大的精力去设计和施工。

软件工程也是这样，做一个小demo一个人花一点时间就可以完成。但是如果做一个复杂度比较高商业软件，那么需要很大一个team的一起协作，UI设计，架构设计，代码实现还有测试保证。工程界在设计的时候，有很多接口的设计就是为了避免对接的地方出现纰漏或者补合适，那么就在设计的时候规定尺寸和大小，甚至用特殊的插口来制约。这一点在航空设计上尤其明显。

那么回到正题，前阵子查找一个bug。后来找到问题所在，是由于：

用的.net中的task api中执行了一个dead loop在里面，在一直查找active proxy,变成dead loop的原因是因为之前的heartbeat只发一次，发生完成之后就把instance release掉了。我查了git history的历史，这几个api在以前是有特定的应用场景也都是正确的。但是在feature变更之后，而且经过不同的developer之手，然后测试的方式没有放在实际生产环境，这几个特定的因素组合在一起，才导致了这个坑。。。

实际上，从设计的角度来说，task这个API过于智能化，丢给系统就不需要管了。但是这种智能风险也很大，丢出去之后就不管这种不负责的行为就导致了这个坑，好在问题比较小，没有引起巨大的内存问题。

其实作为task这个API完全支持cancel，timeout cancel等动作的。
MSDN：https://msdn.microsoft.com/en-us/library/dd997396(v=vs.110).aspx

微软也给出了官方的sample可以去参考。
好吧，每次我使用新API的时候去Google一下看起来是个不错的习惯。：）


在code review的时候，总会遇到各种各样奇葩的代码和设计。正所谓踩过的坑多了，以后走就会避开了。

所以去研究一下《代码大全》这本书吧。

下图为告诉公路的各段弯曲设计，来保证行驶安全和驾驶员的注意力。

11.2更新
在看《代码大全》的时候看到了用建筑工程的方式来比喻软件构架，amazing。然后这篇文的主题，应该是防御式编程的范围。其实总之就是不要相信调用我的方法的API，也不要相信我调用的API，这个道理在情感上比较不好啊，但是在工程中确实不错嗯哈。