UT的争议 from coach eric
在开发产品代码中是否作UT一直是一个有争议的话题。
scrum支持者们喜欢建议开发者在开发产品代码的同时就写下UT，使产品的质量可控。
APO们不太喜欢UT，因为写UT就意味着开发时间*2。也许它能减少debug的时候，但眼前开发才是最紧急的事情。
产品代码全部做UT是一个很大的effort，而一点都不做也面临着质量的风险。关于是否做UT，并没有准确的答案。这是一个权衡，关键怎样把握这个度。
首席coach在一次workshop中发表了它的观点，结果并不重要，喜欢他的分析过程。
理论分析
为什么要UT？
因为UT能及时发现修改代码带来的产品。
对于复杂的代码，UT可作为阅读文档。读者可以通过UT来理解代码的功能、目的、使用方法。
因此经常要改动的代码、复杂度高的代码、容易出错的代码需要UT。
为什么不要UT？
因为UT需要额外的工作量。
对于大量调用别的库的代码，打桩会非常麻烦。
因此对于大量调用其它库的代码，不适合UT。
定性分析
从两个角度来考查一个代码，分别是（1）复杂度、修改频度（2）UT代价
这样可以把代码分成4类：
（1）复杂度高、常修改、大量依赖其它的代码，例如上层业务相关
（2）复杂度高、不依赖其它代码的代码，例如特殊的复杂算法
（3）复杂度低、大量依赖其它代码的代码，例如适配层
（4）复杂度低、但不依赖其它代码的代码，例如功能简单的库
其中（2）应当尽可能地UT，（3）的UT意义不大，（1）（4）则视情况而定
定量分析
这只是简单地对代码分类，如何考查一个代码是否需要UT，而需要进一步判断。
可以通过现有静态分析工具计算代码的分支数、通过提交记录来分析代码的修改频率，以此计算代码的必要性。
通过静态工具分析代码的扇入扇出，以此计算代码UT的代价。
通过代码的UT必要性和UT代码可算出一个代码UT的性价比。
最后通过项目开发的实际情况，有目标地选择一部分代码进行UT。