前几日QA同学给我们讲代码可测性，提到了一个很好的概念：代码的入度与出度。
入度就是说其他模块调用你的模块的次数，出度就是说你的当前模块调用其他模块的次数。
-> 入度 -> | Module | -> 出度 ->
简单来说，就是可测性好的模块一定是入度更大，为别的模块提供了丰富的功能，而又很少依赖其他模块。
我们把模块级别拓展到服务级别，这个道理也是一样的。 好的服务一定是提供的丰富的功能及接口，而又没有太复杂的关联关系及服务依赖。
同理，上升到业务级别的时候，如果你的入度更大，很有可能就属于所谓 “核心业务” 那部分。就以amazon云服务为例，amazon把自己的“核心业务”做成公有服务拿出来卖：虚拟化、存储、计算、网络服务，更上层的有消息服务，支付服务等等。 看起来好像这些东西在一个大一点的公司应该都有，前几日的g+上的 “google 工程师大吐槽” 大致的意思就是amazon有的我们都有，为啥人家弄得那么好都可以拿出来卖了而我们却是一团团？
amazon把自己的“核心业务”拿出来晒，在整个业内增加自己的入度，google自然看了着急啊。
代码总是人写的，当具体到一个工程师的时候，这个法则似乎也适用。很多工程师都觉得每天忙到累到不行行，但是却感觉没什么收获，别人对自己的评价也不高呢？为什么只剩苦劳没有功劳呢？
回顾一下自己做的工作，是入度更大，还是出度更大？
那些出度更大的工程师，通常需要经常与各种人沟通，寻求各种帮助，约定各种接口，这通常是一个极消耗精力的过程 —- 比如面对各种异构系统解决自己的问题。
这时候就需要反思了，如何才能增加自己的入度，给别人提供服务？
或许从每一行代码就可以开始增加自己的入度吧：
我的代码是不是可以复用的？
我写的模块是不是可以作为公共库使用？
我目前的业务线是否可以做成公共服务供别人很方便地调用？
我的业务经验是不是可以share的，哪些是对别人有价值的？
….
顺着这个思路，我相信你一定能成为“高入度”的NB工程师。
已阅