这学期我们学的课程叫做软件体系架构，工作多年以后，我们肯定有的人会成为架构师，那么，如何做才能从一名程序员，小编程，转变为一名架构师呢？结合网络上的文章，谈谈自己的认知。

首先我们定一个基准点：架构师只是功底深厚的程序员，千万不要成为不会写代码的架构师。

架构师应该是立足于技术和业务之间的中间角色或者平衡点， 在针对业务深刻理解的基础上，针对业务中存在诸多变数，挑选适合的技术架构和技术方案。可以这样说，一个架构师工作的好坏决定了整个开发项目的成败。

序员从初级、中级、高级再到架构师，是一个不断经验积累的过程，但是在这过程中我们常常很迷茫，不仅仅是面对技术繁杂的无力感，更重要的是因为长期埋没于代码世界的浩大的分工体系中，无法看清从业务到系统架构的价值链条，无法清楚定位自己在分工体系的位置，处理不好自身与技术、业务的关系所致。所以在程序员生涯中除了技术实力以外，其它软实力也不容忽视。如：主动学习、积累经验、控制注意力、超越自我。

解决问题能力

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

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

学会提问

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

有礼貌

毕竟谁也没有义务帮你解决；

问对的人

选择相关主题的板块，不要多次发布相同问题！

主题清晰

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

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

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

描述要准确

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

描述要客观

不要加主观判断；

描述目标

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

想提高自己解决问题的能力，首先得学会如何提问。给自己提问或者向别人寻求帮助时。