工程师效率

文/Tim Yang

很好奇程序员这个群体这些年效率是变低了还高了，在社交媒体中，各个阶层的兴趣圈都有自己的段子手及内容帐号，段子手发的内容会让你笑 cry，内容帐号发的内容可让你享受阅读的快感，这些快感会比写代码见效快。写完一个模块的代码通常要一整天或者几天时间，代码调通运行没有问题才会体验到愉悦，而社交媒体只需要一些碎片时间就可以达到高潮。相较之下高低立判。而据说这种让大脑愉悦的神经元连接方式一旦新连上就非常稳固，结果就是让人欲罢不能，这样当他在写代码的时候，大脑会下意识的切换去刷下微博及朋友圈。只要不是最后交付关头，总是有弹性的空间去干点别的，因此这些效率的损耗连自己也无法得知。

但在另外一个方面，资讯流动加快，在一定程度上导致社区中优秀软件的复用程度提高。几年前还记得 NoSQL 遍地开花，每个公司里面也都有一个 PHP MVC 框架之类。慢慢的跟社区版本一比较之后，业界百花齐放的现象就慢慢消停了。这几天在看一些技术会议的 slide，发现大部分内容已变成各种开源软件的技术选型技巧，不知是否矫枉过正了。协作程度的提高，也可以视为软件已经逐渐迈向工业社会，有了真正意义的上下游，形成了分工与合作。从这个角度来讲，工程师只需要在自主研发还是拿来主义之间做个选择题，从整体的角度来说，研发效率就得到了提升，视野的提升弥补了 coding 下降带来的效率问题。

影响工程师效率还有一个因素是来自大公司里的流程，由于“全栈工程师”还没得到广泛的理解及接受，因此不同栈之间的工程师之间新开发的模块，存在一个联调的过程，如果他们属于不同的部门，则联调的周期会更长。软件开发完成到上线之前，还需要经过测试部门的测试。因此，即使在代码中加个空格，有时候也需要一周的时间才能到线上。

大型系统中还存在模块耦合的问题，由于多个模块由不同的人员及部门维护，因此给调试及持续集成带来很大的挑战。不少公司中很多代码只能做单个模块的测试及集成，由于依赖复杂，测试环境很难搭建，最后只有线上才有一个包含所有模块的运行环境，因此一段代码如果要依赖上下游才能验证正确性，则只有等到上线后才能判断是否存在 bug。