IT行业软件开发人员-如何循序渐进向架构师发展？

大家好，今天我跟大家聊一聊，对于一个编码人员你如何逐步的具备软件架构设计的这么一个能力。因为经常我也收到很多朋友给我发的私信，询问我如何从一个编码人员快速的形成成长为一个软件架构师？

—1—

实际上我们可以看到，你从软件编码到能够做设计到能做软件架构。它一定是有一个三到五年的周期的积累，对于这个过程没有速成。而你要从软件编码转到能够做软件架构，我个人的核心的理解包括。

第一个点，你仍然需要大量编码过程实践。

因为你接触的项目多了，参与的编码多了，做的功能模块的开发多了，自然而然你在大量的积累后才会去考虑我如何去做归类如何去做抽象。你没有大大量的量的这个积累，你连素材都不够，你怎么样去做抽象？

第二个点，在编码阶段就需要培养设计意识。

在编码阶段你就要去培养我们常说的一些设计的意识和设计的思维。

因为我经常观察到有一些开发人员，他当他拿到一个功能需求的时候，其实这个功能怎么实现？

这个时候在他脑袋里面完全还是一团浆糊的时候，你就会发现他已经动手写 再写代码了。因此往往就是他想到哪里写到哪里。如果在这种方式下面你就即使工作再久也很难去实现和提升你的设计能力。

你具备的一些设计思维并不是说你一定要用什么标准的UL建模工具，去做了完整的建模才叫设计工作。

当你接到一个功能需求以后，你自己能不能在白纸上面用笔画一画，整个实现的流程，实现的核心的逻辑，究竟会涉及到哪一些关键的类？你完全可以提前把这些事情想清楚后再开始动手去写代码。

比如原来我在早期参与工作的时候，更多的就是什么呢？

当一个大的功能需求来的时候我们一般先应该把相应的类规划好，类里面的核心的方法规划好。然后才下一步的动作才是开始写具体的实现的代码。这些都是可以参考的方法。

第三个点 我一直坚持的观点就是源代码就是设计。

并不是说你实际输出的代码要写多少注释。写的好的代码应该具备自解释性，小到一个常量和变量的命名，本身就应该有明确的含义。

所以我们在写代码的时候你一定要去注意整个代码的逻辑是不是清楚，它的可读性究竟怎么样？这个代码转给别人去做维护的时候别人是不是很通俗易懂？你对于大的方法函数是不是进行了相应的一些拆分？你涉及到的一些共性的方法是不是提取为公用的方法或者是函数？该抽象的一些关键接口是不是做了抽象？整个代码你是简单的实现了基础的功能还是你足够的考虑了这个代码它本身应该有的健壮性和可靠性？该做的异常捕捉你都做了处理？该记录的日志是否都做了记录？代码实现该考虑的扩展性是否都做了考虑？

这些东西不是说你到了设计阶段才能做。实际在你编码阶段，你编码多了以后 你自然而然就应该去考虑这些问题。因为编程思维的本质它就是一种抽象和复用的思维。这些能力完完全全可以在你编码阶段去做积累。

—2—

第一个阶段完了以后 过渡到我们讲的第二个阶段。在第二个阶段你要去培养你架构设计的能力的时候，这个时候就有几个关键点了。

第一个点 掌握形式化进行架构设计的通用方法

你需要具备一些我们常说的形式化进行架构设计的一些通用方法。

比如说我们常说的基于UML的面向对象的分析设计。你知道怎么基于4+1架构视图的思想，通过用例图，类关系图，活动图和序列图等去描述核心的架构运行机制。这一些基础的理论知识你仍然需要去学习。

第二个点 重构加设计模式学习

第二个点就是结合你原来大量的编码的一些经验，我个人更加推荐的就是重构加设计模式两个内容一起来看。

你不要单独去看设计模式。因为设计模式本身也是前人大量实践总结出来的一种应对软件可扩展和变化的方法。所以更多的你还是应该去看类似于软件重构的书。

你去学习软件重构的过程中你自然而然就会涉及到相应的一些设计模式的思想。让你逐渐的知道你整个软件架构的搭建怎么样，做到更加可复用和更加可扩展。

第三个点 培养你的架构思维 

对于架构简单一句话来讲软件架构它就是分而治之的艺术。

在整个分而治之的过程中你可以看得到，当我们面对一个复杂的业务需求和业务场景进来的时候，我们首先要具备大拆小的能力，将复杂的东西进行分解，把它拆分为多个组件或者是多个子系统。

在拆解了以后，你还要去设计每个组件或者是子系统，它应该暴露对外的接口。因为组件和组件之间只有通过接口去协同起来，最终才能够满足你最终的需求和业务流程。

分解只是第一步，更加重要的是在分解以后，你还要能够把各个组件最终再集成回去，形成一个完整的整体，这个就是核心的架构设计的思想。当然在整个架构设计的过程中，你同时还要去考虑抽象和复用，考虑有哪一些共性的能力可以把它抽象为独立的业务组件或者是技术组件。

当你具备了我刚才说的三方面的知识的积累的时候仍然是需要你有很多项目实践的机会，在项目的实践的过程中不断的去完善你的架构设计的技能。

所以架构设计的东西绝对也不是简单的你看过 一两本类似于软件架构的书领域驱动设计的书，你就能够具备完整的架构设计能力，更多的仍然是你去参与大量的架构设计实践，在实践完以后才能够回答你最终架构设计的输出是不是能够真正的上线，真正的满足业务系统的需求，同时在系统上线以后你还可以逐渐的去完善你原来架构设计中出现的类似于集成的问题，类似于性能的问题 类似于可扩展性的问题。

个人架构设计的能力的提升就是不断的迭代你原来架构设计不足的地方，从而才能够形成一个完整的架构知识体系。