后端技术 by Tim Yang

很好奇程序员这个群体这些年效率是变低了还高了，在社交媒体中，各种各样的段子会让你笑cry；各个兴趣圈都有一大堆内容帐号，其源源不断产生的内容可让你享受阅读的快感。这些快感会比写代码见效快。

但是完成一个模块的代码通常要一整天或者好几天时间，中间最好还不能间段，最终只有运行没有问题才会体验到愉悦；几年前也曾经实验过，让工程师在编写代码时候，如果被各种事情打断（比如产品汪来访），就在身边一张空白表格标注一下，结果一天被打断十几次是很正常的情况，而工程师被打断一次，通常需要5-20分钟才能恢复回原来任务正常的状况。

而社交媒体只需要一些碎片时间就可以达到高潮，等电梯不到一分钟的时间也会让你有机会对着手机傻笑，相较之下高低立判。而据说这种让大脑愉悦的神经元连接方式一旦新连上就非常稳固，最终会欲罢不能。当他在写代码的时候，大脑会下意识的切换任务去刷下微博及朋友圈以便得到放松及愉悦，而coding时被别的事情打断的创伤更是需要一些补偿来抚平。只要不是最后交付关头，这些效率的损耗无从统计，往往连自己也无法得知。

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

但这也带来一个群体智商下降的问题，大前研一在《低智商社会》中提到

这样导致的结果是，时下流行语中对社会问题所定义的“中低阶层”的范围在不断扩大。所谓的“中低阶层”，就是指身处其中的年轻人对工作和学习都缺乏兴趣，而这种兴趣的缺乏加剧了中产阶级社会的崩溃。

随着信息化社会的高度发展，人们对手机和互联网的依赖度越来越高。在这种情况下，年轻人的思考能力和交流能力面临日趋下降的危险。甚至有种说法称，当代年轻人只关心自己周围3米以内的事情。

当然，“智商衰退”并不仅仅发生在孩子和年轻人身上，连大人们也在做着令人难以置信的事情。比如说，电视节目里一说到“纳豆对减肥有帮助”，他们就会不假思索地立刻去买。第二天日本超市的纳豆竟然被抢购一空。继纳豆事件之后又发生了香蕉的抢购潮。

当前技术圈情况也差不多如此，一种新技术只要得到宣传，就会一拥而上，把使用新技术当做战绩，各种技术会议充斥着各种新技术使用的技巧的分享。而新技术一旦在国外受到了质疑，技术圈马上就会变得茫然，比如“LinkedIn都不用Scala语言了，那我下一步怎么办？”

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

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

苹果经常喜欢用“Reinvent”这个词，用在硬件领域确实高大上。但在软件领域Reinvent大多时候是个贬义词，软件领域上下游结合及相互依赖非常紧密，没有哪个团队甚至公司能封闭的完成所有事情。因此重新发明这件事情在软件领域并不吃香，一个新的体系在小的团队通常会自生自灭（尽管途中可以获得一些荣誉），剩下那些硬撑的项目则会让参与人员痛苦不堪。

比如各厂定制的各种百花齐放的框架，运作几年之后，核心系统越来越臃肿，随着人员的更替能深入了解内部的人也越来越少，改进的动作非常迟钝。但大量的上下游业务服务又需要依赖这些系统，新来的人需要较高的成本熟悉整套系统。问题丛生，但是离开又需要付出极大代价，于是就成了一个鸡肋。如果使用方牵涉到多个部门，更不会有人站起来说将这些定制系统废弃或迁移。

但这个现象在计算机语言领域则是一个例外。一门新的语言，不喜欢的人可以不用，而且大部分开发团队是随大流，不会选用小众语言，所以新语言领域已经在搭建的哪些不成熟的系统也不会给业界带来麻烦及痛苦。少量情况下，极客会心爱的小众语言搭建的一些系统，但根据观察，这些系统通常会随着极客的离职马上会被用主流语言重写替换。因此在新语言领域，可以用更轻松的心态去重新发明各种组件。

一门语言出来之后，复用另外一种语言的模块与组件不是最佳方案，理想情况会选择构建自己的函数库，框架，开发工具，测试工具，代码工具，性能调优工具等。在新的语言出来的早期，这些领域一片空白，踏入这片领域的人会有新大陆淘金的感觉，随便写点东西，很快可以找到市场。

在一个新的语言重写一些别的语言已经完成的项目，尽管这不是什么伟大的发明创造，但参与的人往往更快的取得了成绩并且赢得了尊敬（相对于在“主流”语言拼搏那些人）。我也曾经思考过这个现象。技术人的价值观虽然很多元化，但是有两点却几乎是共通的，一是工程师动手创造带来的成就感，二是感受创造的东西给所在环境以及业界带来使用价值的成就感，不管这些创造是原创的还是山寨。因此在很多领域如搜索、广告以及更基础层面OS、Database、Language总是有乐此不疲工程师重新去建设，因此在语言层面的重新建设就变得容易理解了。

更深层次的来看，在语言层面的基础上，重新去构建一个生态圈，从社区的角度，不只是重新克隆一个新的版本，工程师会考虑以往的经验及教训，重新设计重要的单元，以带来性能上的提升及使用方式上的改进。比如这几天写一个Go语言的小程序，看到Go的社区在配置文件方面的思考及重新选择。配置管理在Java领域大多是XML一统天下，尽管其可维护性较差，但由于历史原因，工程师很难去另起炉灶。

当然在新OS领域重新创造的机会就更多，但是这种情况较少发生，一个新的OS生命周期会延续10年或更久。一些大公司的开发平台生态圈也有类似的这样的机会，不过大部分情况下格局会小很多，也会存在更大的不确定性。

年轻的同学喜欢按学习曲线来看自己过去的每一年，但是这种方式很快就会步入到瓶颈，学习曲线增长突然会变得缓慢。在2013年圣诞节时，Tim还在每天花上10-30分钟玩一款叫Clash of Clans的游戏，并邀请身边的朋友都加入了部落，当时每天的升级成长也很快。但不知道从哪一天开始，发觉升级越来越慢了，需要2周或者更长时间才能将一些对象升级，所以慢慢的对其失去了成就感、耐心与好奇心。

工程师对于技术的关系也是如此，刚接触第一门编程语言时候，对每一个细节充满了好奇心，发现一种新的语法糖也会兴奋不已。当使用这些技能之后，慢慢的发现工作中只会重复的使用其中20%左右的领域，就这样月复一月的过着。当然学习的习惯还继续保留，工作之外的东西也会去看看其他一些东西，比如花一周学习媒体炒得火热的Swift语言。但较常见的情况是，大家学的这些新潮技术工作中一般不会立即使用，几个月之后Swift怎么写可能一点也不记得了。几次类似经历之后，当再有新的某项技术出来，如果看不到有使用的需要，你已经不打算再学了。毕竟花很大力气学会某项东西，又注定在几个月后会忘记，这种做无用功的感觉很不好。因此最终学习曲线会停滞在某个点。

前几年在新年来临之际Tim也会去给一些技术媒体投稿，彻夜不眠写出一篇技术圈宏大的总结与展望，希望能给从业人员指出一条明路。但是这种凭借个人视野有感而写出来的东西，最终指导不了自己也指导不了别人。技术领域太广太深，即使图灵奖得主也很难去评论另外一个专业领域未来一年的发展趋势，能看到的各种预测无非是主流媒体的观点汇集而已。于是后来就不写（也不看）这种总结展望了。尽管技术领域内盲从的心理还是非常显著，很需要这种指南类的东西（比“干货”受欢迎多了）。

在2014年日常感悟比较多的，就是对昨天文章技术团队的标准化与可复用文化所说的技术群体里面的无序感到有些悲观。当一个低级问题，第一次解决时，你会感受到成就；第二次解决时，你感受到责任，第三次解决时，你可能更多的感受到无力。当你观察一个小的团队时时，这些情况不会明显；但当你把目光聚焦在一个稍大的团队，比如50人以上时，这种问题会更容易发现。

有人倡导自组织团队，包括各级大佬BOSS们也给我们指出这是前进的方向，但是完全具有自组织特征的团队不是很容易见到。Tim身边更多情况是靠各级管理者强有力的执行力去推动。想想如果没有领导的角色可以自运作起来，还是很有挑战的一件事情。当然挑战不包括各种技术大会的那些敏捷教练们。

开源这个词有些滥用，我个人去评价一个项目时候更多的是看它解决的问题以及带来的价值。国内业界的问题不是开源不够，而是能创造价值的软件太少。单纯去讨论开源运动我觉得和讨论”跑步运动“或者”站立办公“没什么区别，虽然我也尝试站立办公，但是我觉得没必要天天挂在嘴上。

运营开源最重要的是社区（指贡献你项目代码的群体），先是有了社区，然后有了你的开源project。否则你的项目最多会成为一个带源代码的一款工具软件。经常的误区是一些人觉得将内部的一堆不再维护的代码上传到github上，然后就期望一夜成名，或觉得船到桥头自然直，这就有点naive了。

虽然大数据很热，但是我认可大部分engineering方向的工程师不适合做大数据这个观点。不是说这些人不够聪明，而是当你已经25岁左右时候，你已经用了3-5年“最好的编程语言”之后，来决定踏入大数据算法这道门，时机有些晚了。大数据的算法是稍微和计算机科学的“科学”二字最搭边的一门学科，这个算法和CS学的那些快速排序算法有很大的区别，通常这些半路进入的engineering类的工程师，最终的天花板可能是一个数据统计工程师或者是协同过滤工程师。即便如此，一代又一代工程类的技术人员义无反顾走了进去，经过半年一年狂热的学习之后，在一些大BOSS不理解的岗位上默默的发挥着作用，并坚信自己已经是迈向金矿的康庄大道上。大部分没有Critical thinking sense的工程师，习惯在因与果之间用“自然而然”推理并联系起来，比如“只要我进一步学好大数据算法，自然而然，就能挖到金矿”。

2013年元旦时候也写了一篇谈分享、创新与开源，和目前想法也有些明显的区别。