我们来讲一个故事，一位旅行者路过一个烈日下的工地，所有人都在那儿汗流浃背地搬砖。

旅行者问第一个人在干什么，那人头也没抬地回答：“我在搬砖。”

旅行者问第二个人在干什么，这个匆匆抬起头认真地说：“我在砌墙。”

旅行者问第三个人在干什么的时候，那个人脸上充满了光彩，很自信地说：“我在盖圣玛利亚大教堂。”这个故事是不是像极了我们从事软件开发工作的不同阶段的不同状态。每当听到从程序员到架构师的书或者文章时，我们总是充满好奇，想从其中获取一些观点亦或是技能点，接下来我们就详细讲讲一下，如何从程序员走向架构师。

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

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

开篇的基准点：架构师只是功底深厚的程序员；

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

卓越的程序员

对于一个卓越的程序员来说，编程技能毋庸置疑是很重要的。但是，除了基本的编程开发能力，其他方面的能力也是体现一个程序员的能力的很重要因素。比如，问题排查能力、线上运维能力、项目管理能力、协调沟通能力等。

我们先看IT市场对于一个不同阶段的程序员的要求：

初级开发工程师

职位要求

综述：主动性，积极主动，能够主动了解相关业务需求，在上级的领导和监督下定期完成量化的工作要求；
项目管理：不需要项目管理的能力，具备管理简单模块开发任务的时间点。
开发语言技能及架构能力：
- 能独立处理和解决所负责的任务；
- 根据开发进度和任务分配，完成相应模块软件的设计、开发、编程任务；
- 进行程序单元、功能的测试，查出软件存在的缺陷并保证其质量；
业务理解：根据产品需求PRD理解简单模块的业务流程，根据业务流程书写相应的开发流程，能够根据自己的理解评估模块开发的时间点。
影响：能影响同级开发人员，得到项目组认可。

中级开发工程师

职位要求

综述：独立性，根据项目具体要求、承担开发任务，按计划完成任务目标。
项目管理：具备有一定初级难度的项目（如链路较短\模块复杂较低\风险较小\发布周期不紧）的PM的经验和能力。
开发语言技能及架构能力：
- 理解产品文档，参与需求评审、需求分析、系统设计；
- 负责确保项目的进度和质量；
- 整理和提交相关设计文档，对负责的功能模块有自测习惯；
- 对所负责的模块有维护责任，有问题及时解决。
业务理解：熟悉自己负责的业务模块，对业务模块的流程有独立的思考，产品设计时能给出合理有效的方案建议；
影响：
- 能影响项目的成员，是团队内公认的主力成员之一；
- 加分项：有良好的分享习惯。

高级开发工程师

职位要求

综述：自主性，独当一面，能独立主导和推动项目及任务，在专业领域具备辅导他人的能力
项目管理：具备有一定中等复杂度的项目（如链路较长、模块复杂度较高、风险较大、发布周期较紧、技术驱动等）的PM经验和能力。
开发语言技能及架构能力：
- 能独立解决问题，能够负责重要业务模块的需求分析及设计实现。
- 熟悉设计原则，能够在日常编码工作中恰当使用，优化原有设计（有实例支撑）；
- 熟悉编程语言、编码规范、安全规范，具备性能意识，代码具备高可读性；
- 了解常用框架背后的原理。
业务理解：
- 熟悉自己直接负责的业务，对业务产品具有独立沟通，完善业务需求；并识别方案的风险能力；关注自己参与项目的业务数据；
- 能够在所负责的业务及产品上有独立的见解，能提出合理的建议，更有效的解决业务问题；
影响：
- 影响项目组或产品线的成员，是项目组或产品线公认的主力人员；范围：团队内。
- 加分项：具备辅导他人的能力和技能，有良好的分享习惯。

根据上面的招聘需求，我们来看看作为一个开发工程师从初级到架构师，需要哪些技能和非技能的积累，下面我们就从技能和非技能来总结。

一、技术技能树

架构筑基

开源框架解析.png

高性能架构专题

微服务架构专题

团队协作开发专题

B2C商城项目实战

二、业务自测

一般的研发流程

在上面职级要求中，对于初级开发工程师的要求就是得到项目组的认可，如何得到项目组的认可呢？不管哪个职级的公司成员，首先要对自己做出的事情负责，上面的流程中发现一个问题，功能开发结束提测后，测试成员进行测试的时候，发现功能不能正常运行，无法开展测试工作。这自然是不合理的，会影响测试成员对研发成员的信任、还会影响测试成员的工作积极性，信任就类似刷信用卡，当你的信用值逐次降低，其他成员就很难相信你，演化到最后就是不愿意和你合作，他们认为你是一个不靠谱的人。

当然这个问题很容易解决，只要研发这个环节中增加自测流程即可。

优化后流程

关于研发自测这个环节为什么我们开始没有加上？这是因为，我们一般认为研发人员对自己开发的模块进行自测，是应该的，用研发术语来讲是默认的，不需要另行强调。程序猿的工作是团队协作中的一环，和环上的所有人一样，都应该对自己所做的工作负责，这样对于环上的其他人才是公平的、有效的，团队的整体效率才能提高。

为了让研发成员能进行测试，我们还有些问题需要解决：

测试用例范围问题
被测试环境和测试执行环境的复杂性问题
测试数据准备的问题
测试执行与集成问题
失败测试用例归属问题

这些问题我们就不展开说了，但是业务自测是作为一个开发工程师必要的职业素养。

三、解决问题能力

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

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

日志查看

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

代码检查

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

远程调试

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

本地调试

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

四、学会提问

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

有礼貌

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

问对的人

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

主题清晰

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

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

描述要准确

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

描述要客观

不要加主观判断；

描述目标

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

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

五、总结

我们日常遇到的问题就类似打怪升级一样，你解决的问题越多你的能力就会越强，经验自然也会越来越丰富。但人的脑袋不可能记住所有事情，将自己遇到的问题沉淀下来对以后自己查阅也有很大的帮助，就不必每次都要去Google，自己也能够有一个索引库。经常自己总结，也能够提高自己的写作能力，以后写文章、ppt总结提炼自然也难不倒你了，也是一举两得的事情。还有你以后求职面试过程中，提及自己这方面的能力的时候，也能够为自己面试加分哦。

一个人能产生多大价值取决于他的影响力有多大，之前看到有人在我们内部论坛提问说提高影响力有什么用？你看看马云就能知道有什么用了，他说一句话比你说上百句都管用，毕竟人家的影响力在那里。我们程序员做知识经验的传承，不仅能够提高你自身的影响力，还能够帮助你提升逻辑思维能力，因为你需要去总结提炼，你需要将问题梳理清楚，并且要将知识点描述得能够让别人更容易接受。你的经验虽然是你自己的，但如果你的经验能够帮助到别人，那你的价值就不一样了。