2016 at 即刻

2017-01-01 23:37:00

又是一个普通的日子，被闹钟吵醒了，我下意识地打开了手机，来了一条推送，是微信的消息，推的是 protalk 的评分监控，今天很给面子，所有的新评论都是5星，但这也意味着并不能从其中获得更多的信息。

出门坐上地铁，地铁上刷即刻，看到 Android Developer 更新了，说的是 2016 年的总结，总体的意思就是 stormzhang 从技术转管理了。接着刷即刻，看到 Android 群英传也更新了，医生说这是今年的最后一篇投稿。他们也有点意思，因为前者说喜欢原创，认为接受别人投稿不算真正意义上的分享，而后者恰恰是好几篇中才有一篇是医生本人写的。后面又刷了一会儿即刻，我把技术的公众号都退订了，因为对聊天的影响太大，全部转战到了即刻（实验室可以定制微信公众号更新）。

我突然意识到一个问题，我太依赖即刻了，在大众点评的时候我也没有很依赖大众点评的客户端，仅仅在吃饭的时候才会去打开，而且推送什么的也是全关了的。这是一件值得思考的事情，因为大多数开发者做的 app 都是给别人用的，他们自己并不是该应用的重度使用者或者目标用户，这对用户来说并不是一件好消息，因为开发者如果不经常使用自己开发的东西，是很难把体验做好的。

以即刻为例，即刻目前为止还没有测试工程师，也许未来很长一段时间也不需要，因为几乎所有的业务场景，在我平时使用的时候都会碰到，一旦发现体验不好，就会自我驱动去优化，优化后第一个享受到体验提升的就是我自己，多么爽的一件事啊。那么会有很少遇到的业务场景吗？应该不会，因为这种情况只在大公司会出现，是 to KPI 的功能。

记得早些时候我就和天之界线2010说过，如果你开发的应用你自己不经常用，那么你几乎不可能把它做好，需求和优化永远都是后知后觉，等到用户反馈或者产品经理提需求了才去做，做完也不会去想为什么要做或者怎样做得更好。

还有一位优秀的开发者是 drakeet 许晓锋，他有很多优秀的开源项目和个人 app ，给我印象比较深的两款应用是纯纯打码和贝壳单词，他对代码是比较执着和有洁癖的，而我需要注意的是对代码或架构的重视程度不能大过对产品本身。

这时候我想起之前看的左耳朵耗子前辈的一篇文章《技术人员的发展之路》，文章本身关注的是技术人的职业规划，其中的道理也可以用在其他地方。如果你做的事情是有意义的，那么总有一个最优路径去把这件事做好，而对 app 来说，最优路径要考虑的因素有很多，技术只是其中一环。

我一直说技术和语言没有高低之分，也无所谓擅长或者不擅长，这是你达到目的的方法，只不过在互联网的大浪潮下，技术的重要性被重新认识了。

再看 2016 这一整年，技术圈撕逼的不少，互相举报文章抄袭的也不少，写博客的不少、出书的也不少。可是，好应用却不多，再想想我们为什么会觉得扎克伯格厉害，不是因为他技术有多牛逼，是因为他做了 Facebook ，我更希望在 2017 年看到更多优秀的 Android 应用，并通过这些应用，去感受开发团队的匠心。

说回即刻吧，我之前发过一条微博，说即刻 app 的优化，一张纸也写不完。那么到底有哪些优化可以做呢？主要是这几点： ui 设计、技术架构和代码品控、需求和场景的匹配程度。

即刻的 ui 总体上来说会让人眼前一亮，这是因为交互一致性做得还不错，但是如果深究其细节的话，还是有点粗糙的，并没有做到工艺程度的交互一致性。比如颜色、字体大小、点击反馈、页面跳转，等等。如果后面有时间，会详细做一个交互一致性的迭代规划，这并不只是设计师的事情，尽管我们已经有了一套初步的设计规范，但这是远远不够的，如果只懂技术不去关心交互设计，想开发一款优秀的应用是不可能的。

技术架构决定上层建筑，但是说到底是提高可维护性，稳定功能的下沉、新功能对旧代码的复用、这些老生常谈的东西，优化是没有止境的，也会带来其他的工作，如瘦身、编译时间的优化。我们对开源项目的使用比较节制，对开源项目的刨根问底也是新的一年需要做的工作。而代码品控，对代码质量和规范的要求在新的一年会更进一步。

需求和场景的匹配程度，很多工程师做完需求就结束了，因为不常使用，并不会去思考其中的因果关系、前后逻辑和需求闭环。比如需求如果和设计、实现出现矛盾了怎么办，会不会是需求本身的问题。这个需求实现用了太多的代码量，这个需求未来有没有可能砍掉，对拉新和用户留存有什么帮助。站在工程师的角度，或者说通过工程师角色的思考角度，是不是能提供不同于产品和设计的思考呢。