工作随记

最近工作了几个月，在这里稍微反思一下有哪些常识需要提醒一下自己。

其一是很多东西并没有想象中难。

刚刚入团队的时候，我觉得做的东西是个框架，是个很高大上的东西，很多我很崇拜的人都在做，一定很难。于是我写起代码来束手束脚小心翼翼，改一行代码想一下午。后来看到了很多TODO和很多代码库里本身就不是很完美的代码，后知后觉这玩意儿其实也是人写的。我们很容易用框架的时候用仰视的眼光去看做框架的人，用仰视的眼光去看待哪些我们不懂的领域。但其实不一定是因为上层或是上游的人比我们更厉害，只是大家各司其职有不同的考量而已。写产品的更重视迅速的将某个非常具体的需求呈现出来，写框架的更重视多花些时间把API设计好，能够满足各种下游用户的需求并且容易维护。

刚刚开始开发的时候，关于编译的所有指令都是按照documentation照抄的，build出了什么问题若没有documentation便觉得十分无助。觉得写build脚本也貌似很难的样子，所以有什么问题只晓得给别人发feature request。当时用heroku来deploy代码用于移动端测试。这个过程很坑，要等半个小时。大家都冥冥中知道用firebase会快很多，但不知道为啥没人弄。其实我也吐槽deploy时间长很多次了，拖了很久没弄因为怕这个东西很难然后很久搞不出来。后来因为要测一个需要经常deploy的bug修复，heroku当时刚好坏掉了，不得不把firebase搞懂，就跑去研究了一下。然后发现这玩意儿只不过是改掉几个url然后一个scp，索性写了一个JS脚本加进了gulp task。写了这个才发现原来很简单，原来所有的编译脚本其实源代码很好懂。后来大约是documentation写得不是很清楚，常有同事跑来问这玩意儿怎么用。然后反向体会到我刚开始给别人发问题的时候，其实应该做的第一件事是找那玩意儿的源代码看看，因为也许自己改改其实不难。

总之，凡事应该养成看源代码的习惯，上游和工具的维护者也都是人，大多数的小改进比想象中简单。

其二是百封邮件不如当面开个会。

上个季度同一个时差16小时的同事合作。我写了个API，同事在用。关于这个API，同事发bug和问题，我修bug回复问题，整个邮件盖了100多层楼，简直坑爹。经常双方讲不清楚bug到底是不是我这个环节的bug，修复方式为什么不能work。两边都有锅。后来不能忍了，早上6点爬起来同这位同事打了个视频电话，不到一个小时全讲清楚了。后来吸取了这个教训，又有别组的同事发issue，干脆直接走过去他们的楼把issue上的同事全部都逮着认识了一下然后当面问了一下这一坨bug。事情三言两语就讲清楚了，省掉了两边一堆的邮件。

其三是其实很多失误都源于误会都源于“我以为你懂你以为我懂但我们各自懂的都不是同一个事儿”。

例子太多，但好像不好举。总之得出的教训就是，在多方合作的时候最好不要想当然。因为有的时候你的想当然和别人的想当然是完全两码事。比如说有些团队的P0是两周内解决，有些的团队的P0是两分钟内解决，又比如说设计师眼中的“可以发布了”又同程序员眼中的“可以发布了”是两码事。凡事若有疑问就干脆白纸黑字的写下来，开会各方确认一下，然后得出结论再白纸黑子的写下来，邮件总结一下。这样日后若不记得到底决定了什么，也有个记录可循。

其四是很多看起来不是正事儿的东西其实是正事儿并且要费很多时间。

比如说绩效考核，比如说写面试反馈，比如写设计文件，比如说开会和沟通。总之，“唯有写代码才是正事儿”，大概是程序员生涯里最骗人的一句话了。

其实这些道理都很显而易见，但太容易忘。