原文地址：

架构师只是功底深厚的程序员，千万不要成为不会写代码的架构师。

架构师应该是立足于技术和业务之间的中间角色或者平衡点， 在针对业务深刻理解的基础上，针对业务中存在诸多变数，挑选适合的技术架构和技术方案。

可以这样说，一个架构师工作的好坏决定了整个开发项目的成败。

作为一个开发工程师从初级到架构师，需要哪些技能和非技能的积累？

除了必须的职业技术技能之外，还要学会业务自测，业务自测是作为一个开发工程师必要的职业素养。

而且还要拥有解决问题的能力，解决问题能力不是天生的，自然得靠后天的经验积累。我们工作中会遇到各种各样的问题，比如需要去跟踪调试产品所产生的bug，又比如说使用第三方组件所遇到的一些问题，再比如说使用一些插件或者IDE所产生的一些编译问题。这个时候第一反应不是去别人那里寻求帮助，而是自己尝试去看去解决问题。

当遇到阻塞性问题的时候，需要立即排查并处理。由于是线上的环境，我们在排查问题会有一定的难度，但依旧有一定的方法可寻，一般按照如下步骤进行。

1.日志查看：从日志中查看到报错的信息，依据这些信息进行问题排查，比如什么时间、什么人、操作了什么、触发了什么、产生了什么结果。

2.代码检查：在日志无法排查问题的情况下，需要通过代码来定位。这需要对代码有一定的熟悉程度，可以知道用户的操作是由哪里的代码执行的，然后对该块代码进行检查。代码检查的时候需要着重检查一些逻辑分支语句，同时可以借助一些工具，例如：FindBugs，Alibaba Code Guidelines等。另外，还需要关注一下触发器之类的隐蔽代码。

3.远程调试：由于代码是静态的，而代码执行是动态的。静态代码的检查可能并不能检查出问题，而需要通过线上的环境、数据一并进行检查。这时，可以在不影响线上用户使用的情况下，远程断点调试程序。

4.本地调试：有的系统可能并不方便进行远程调试，那么可以尝试把线上的全部数据（或者关键历史数据）拷贝下来，在本地环境使用线上环境的数据库，进行调试。断点调试是比较直观的一种检查错误的方式，通过异常信息的日志，能确定到指定的代码行，并结合线上的数据，很容易发现问题。

还有一点是要学会提问，问问题的能力是一个人的修养，学会提问是一个人成长的必经之路。尤其是软件行业的从业者，要保持对技术的钻研精神，不做伸手党，问出水平，问出修养！

在问问题时要注意以下几点：

1.有礼貌：毕竟谁也没有义务帮你解决；

2.问对的人：选择相关主题的板块，不要多次发布相同问题！

3.主题清晰：问了让别人不用看描述就知道问题类型和背景，github一般都会对issue做tag标记的。

较差的标题：保存，老实提示系统异常。

较好的标题：在firefox中保存时导致系统异常的兼容性问题求解。

4.描述要准确：描述机器环境(os，机器配置，版本信息)；描述自己的排查方向和相关现象；描述问题的触发背景(升级了什么组件/改了什么)；提供复现方法。

5.描述要客观：不要加主观判断；

6.描述目标：不是中间的某个步骤step；可能你的方向偏了，实现目标根本就不需要实现这个step

想提高自己解决问题的能力，首先得学会如何提问。