从工程师到架构师

从第一次写出Hello World，到成为一个优秀的工程师的距离有多远？

从工程师到架构师，又需要多少技术与非技术方面的积累？

在工程师职业发展的过程中，不仅会遇到各种技术问题，也会遇到各种技术以外的项目问题。如何解决这些问题，是每一个工程师进阶之路必不可少的经历。

现在有许许多多的框架,比如常见的

网络访问：

Android-Async-Http okhttp retrofit volley xutils。。

图片加载：

ulmageLoader  fresco picaso xutils glide。。。

图标框架：

AChartEngine MPAndroidChart HelloChart WillamChart。。。

我们也都知道，这里许多框架是基于已有的框架再次封装，比如retrofit就是封装了原有的okhttp，volley就是集成了异步。。

即使封装了一次，也是无法满足到许多需求，比如你手握volleyUtils，万一有一天产品说要你加载个大图，或者大量数据，又要改架构了，结果产品还说我只是要你加载个图片你就说这么复杂（产品经理不是人）。

作为一个优秀的程序员，程序的架构功底是非常重要的。

产品进入版本迭代阶段

产品正式发布以后，如果反响还不错，公司继续在项目上投入。这个阶段，你的业务方向其实已经确定了，所以你需要根据业务情况做一些技术上的调整。

这个阶段，适配性问题开始铺开，不一定来自线上的崩溃，也有可能是来自用户的反馈。用户反馈的优先级当然是比较高的，但此时如果一味的满足用户的反馈，很可能会疲于应付各种bug，你的正常功能开发收到影响。所以，这时候，你应该建立bug分级制度，根据之前我们线上做的app崩溃比率，以及用户反馈的权重。确定哪些bug应该立即修复，哪些应该是稍微延后一点。优先级高的bug，我们就可能自己发个小版本先出去，优先级低的bug，我们可以延后到下个版本去解决。

随着版本的迭代，我们可以做的东西其实很多。
第一个，我们之前的编码规范和ui规范必须文档化；第二个，如果某些项目中的框架是通用的，类似网络库，文件存储库，你把抽离出来，单独成为一个module工程，或者说输出个sdk。这一步其实很重要，但我发现很多团队都没做。第三个，关注android新技术，合理判定某些新框架或新技术能否解决你的业务痛点。

现在获取新技术渠道很多，但我想强调的是，新技术关注肯定要做，这是技术热情的一部分，但需要建立你自己的技术观。我最近也遇到一个面试候选人，聊到新技术的时候，发现他对大部分社区内比较火的技术都比较了解，做过一些简单的demo，也在原来的团队内部做了一些分享。我们当然很喜欢这一类的候选人。但进一步聊，发现他反馈的都是互联网上一些通用的评论，或者是解决方案，基本上就是人云亦云，没有形成自己独立的判断，欢迎不同的观点，但不应该没有观点。

最后，还可以对建立团队氛围。譬如你可以通过制度化分享的机制，或者输出技术文章等，督促团队去主动去学习新的知识，提高整个技术团队的水平。

总结

技术是为产品服务的，并不是说出现需求才考虑技术，在需求出现之前，技术可以同步给产品经理，告诉产品经理我们可以做什么，这样产品策划同时可以根据技术去拓展业务，而不仅仅说技术不拖业务后腿，技术人员也可以达到跟APP共同成长。