几点思考

阅读文本大概需要 5 分钟。

这是 ibrothergang 的第 42 篇原创文章。

按照中国的传统，虽然还没有过年，但是已经离过年不远了。这段时间，往往是公司比较忙的一段时间。年终总结、季度考核、年会、新年目标等等。赶快趁着周末，结合最近的一些工作，做一点回顾，有几点感触比较深。

1. 想太少

程序员拿到一个需求后，往往想的是「怎么做」。怎么样去实现这个功能。产品经理不是万能的，特别是没有原型可以参考的时候，考虑功能也是基于自己的一些想象。工程师在开发功能的时候，是第一线的人员，你在开发的时候，除了思考「怎么做」之外，还需要多想想「为什么」。

比如产品经理提了一个需求，是这样的：让用户打开 app 的时候，检测当前是否有新版本，有的话显示提示框提醒用户更新。

开发实现这个功能不难，请求服务器，获取最新版本信息，如果有新版本的话就提示用户。但是我们有没有想过为什么要有这个功能？有这个功能是为了让用户及时的知道新版本都有了哪些好的功能，让用户能更新到最新的版本，解决一些版本碎片化的问题。如果从这个角度出发，那么一键升级的方式是不是更好，给用户下载好最新版本让用户安装，甚至对用户无感就安装好最新的版本。虽然这个在技术实现上比简单的显示一个弹窗要复杂不少，但是对于一个真正想升级的用户来说，体验上不是好多了吗？

2. 想太多

这个主要指功能开发方面。

程序员多多少少都会带有一点完美情节。一般喜欢给自己的模块设计各种各样的功能，希望出来后就是一把「瑞士军刀」。但是有时候，真正的产品需要的功能并不多，过度的设计无形中增加了产品的逻辑，这部分逻辑往往又是当前产品不需要的，是徒劳的。从投入产出比来看，可能不是很适合当前的开发模式。

所以有时候程序员也需要克制，过多的添加功能反而会让整个开发变得不够快捷和稳定。

3. 解决「麻烦」

很多时候，我们在做一堆的功能，但是好像也没有听到很多用户在赞扬我们的功能做得多好，或者说从数据上也没有反应出这个功能有获得多少用户的喜欢。

大家都喜欢在舒适圈待着。有时候产品提出一个体验比较好的方案，技术会以「比较麻烦」、「不太好实现」、「需要花太多时间了」为理由推脱掉。我也经常做这样的事情。觉得这个方案实现起来没那么容易。花时间还不一定有效果，先做些简单的吧。最终出来的效果就是普普通通，没什么亮点。

现在想想，技术人存在的目的，除了实现功能外，不就是解决一个个的「麻烦」吗。而且有时候你只要真的投入进入，其实会发现也没有那么麻烦。即使真的比较麻烦，你在解决的过程中也收获了宝贵的经验，在实践中知道了这个方案的复杂程度。从这两方面来说，做比推脱好太多。

4. 适合的才是最好的。

有些情况，我们面对的问题不是如何解答，而是如何选择。比如：图片加载我是用 glide 还是 frasco ，播放器是使用 exoplayer 还是 ijkplayer ，插件化是用 DyLA(Dynamic-load-apk) 还是 DPG(DroidPlugin)。

这里面我觉得应该遵循一条：适合自己的才是最好的。当然，在找到适合自己的过程中，可能会需要很多的尝试。

举个我们最近组件化的例子。

考虑到项目的长期发展以及解耦，在这次的开发初期就采用了组件化的方式。将所有的业务都作为一个个独立的组件。这块没有问题。后来为了做到更加的独立，我们又将组件打包成了独立的 aar 包。显然，我们的出发点是好的，这样当开发功能的时候，只要单独引用 aar 包就可以了，加快了开发速度。

但是当我们真正这么做的时候，发现反而使我们的开发速度变慢了。

原因是目前我们的组件更多的是和业务相关联，而组件的业务一旦更改，就需要重新编译 aar。正是这一步，大大的减慢了整体的开发速度。后来及时调整了策略，将 aar 重新以 module 的形式在项目中引用。

从这里我们可以看到，虽然 aar 是组件化一个比较好的形式，但是在当前的资源不足以支撑这块的时候，反而以 module 的形式在项目中引用是最优的。这也是当前适合我们的最佳方式。

以上，就是最近的一些思考，其实归根到底一句话，就是思考怎么样把一件事情既快又好的完成。

晚安！