自己关于软件架构的一些思考。
前段时间听丛斌博士的公开课，里边谈到了中国国内最缺的人才就是软件架构师。我们经常提到软件架构，但到底什么才是软件架构？软件架构和产品设计，需求分析和编码到底有什么关系？
另一个近期发生在自己身边的真实案例：
去年和一个朋友聊天，谈起来他负责的一个公共服务平台建设项目的进展，他说他聘请了一个架构师，已经把软件架构设计完毕了，然后要了一笔钱，说下边应该找个专业的需求分析把需求分析做一做，然后找个编码团队把代码编一下就可以交付了。我听后就觉得我朋友被骗了。
很多人对架构师有些误解，认为架构师就应该高屋建瓴，设计一个框架（类似邓公那样，在一个特定地点画一个圈^_^）给团队说：你们就按我说的做去吧……然后架构师就算完成任务了。而实际上架构师根本不是这样的，或者说这些只是架构师工作的很小的一部分。
什么是软件架构
那到底什么是软件架构？
大神Grady Booch是这样解释的：
“所有架构都是设计，但并非所有的设计都是架构”。
“架构反映了使一个系统成型的重要设计决策，而重要性则通过改变的成本来衡量”。
说的直白点，其实就是设计中的重要决策就是架构。
架构涉及的内容，可能会涵盖但不限于如下几个方面：
- 子系统/分系统的划分与实现方式
- 软件系统的结构
- 框架选择
- 设计方法与模式
- 软件生命周期模型的选择
软件为什么要有架构
我是在十几年前开始做第一个软件项目，用C++写的一个监控程序，规模大概在万行左右。由于刚出校门，程序虽然说运行无碍，但是内部的结构简直一团乱麻。在程序进场联试以后，上级提出了若干次更改，随着更改次数的增多，类型之间的互耦也越来越复杂，到最后只能对程序的大部分内容进行了重构（说难听点就是重新写了一个）。还好功能变更主要集中在几个软件上，系统的整体结构还没有到不得不变的程序，否则损失就太大了。
从那以后，我就开始逐渐重视程序的架构甚至是系统架构的总体设计。提前考虑变更风险，选择的技术方案尽量降低软硬件不同模块之间的耦合，各个子系统、子功能之间相对独立，尽量将通用的东西做成一个“中台”，让系统功能分解成一个个“微服务”。最终实践结果也证明了，小型松耦合的组件可以更轻易的构建、修改、删除、替换以及测试，降低变更成本，提升系统质量。
总的来说，如果你的软件规模小，重要程度不高，日后也不会怎么变动，或者对质量要求不高，只是一些原理性的验证。那么架构的作用就不明显，反之则应该重视。
架构师的职责
在常规的软件研发流程中，架构师应该做哪些工作？我认为架构师的职责应该是贯穿产品生命周期的始终，它像一根绳子，串起来软件研发过程中的所有利益相关者，并需要参与软件产品设计的所有重要决策。所以，我们可以将架构师看成一个非常重要的软件总体角色，它是一种职责而不是职位，在软件设计相关的所有内容中，软件的架构是所有重要内容的集成，也就是软件中最重要的部分，没有之一。那么，根据权责一致性的理论，负责软件架构的人，也就是架构师，就是软件设计与实现的第一责任人。
在安全关键软件领域，是否应该设置架构师
在安全关键软件领域，设置架构师这一职责，将其位置放在软件总师的位置之下或平级于软件总师，把项目中和通用技术（需求的分析技术、软件分层设计、数据库设计等）相关的技术职责划给软件架构师，对项目的发展是有着非常大的好处的。
- 有助于新技术的推广应用。现在大多数项目的软件总师，是所在项目核心领域的专家，但不一定是软件通用技术的专家。由于项目的软件总师一直忙于项目，大多数软件总师对于软件通用技术（如新的语言，设计模式，软件框架，云技术，大数据，人工智能等）都不是很熟悉。由于软件总师压力很大，即使很多一线的软件总师想去学一些新的东西，往往也是心有余而力不足。而计算机行业发展飞快，新技术层出不穷，以至于很多新的项目，明明有更好、更可靠的解决方案，但是软件总师由于不熟悉而不敢采纳。所以，设置软件架构师，负责通用技术，能够很好的补充原来项目组的不足。
- 能够非常好的推进组织的公共资产库的使用。我们很多的组织资产库中的软件资产，得不到很好的利用，原因并不是一线的科研人员不想用，而是由于“部门墙”的存在，部门之间的沟通非常少，一线开发人员不清楚库里的有哪些东西可以利用，以及好不好用。而软件架构师，由于其研究范围主要集中于通用技术，其技术适用性广，人员在课题中的流动性强，因此架构师们受“部门墙”的影响相对较小，其眼界要比单纯从事某一业务板块的软件总师要广，更容易知道整个组织内有哪些资源可以借用。因此，在课题中设置架构师，是可以促进共用资产利用率的。
- 能够解决纯软件人员的职业发展通道问题。目前一些领域和组织，软件人员如果仅仅将自己的能力放在提升软件的设计和编码能力上，发展的通道是受限的，而如果所有优秀的软件人员，都往软件总师方面发展，去做业务领域而逐渐疏离软件设计，（或去当行政领导），也非常不利于组织整体技术能力的提升。而在课题中设立架构师的分工，能提供给在软件开发领域有所擅长的技术人员一个良好的上升通道。
当然，不足和问题也是存在的，比如架构师和软总的职责在一些方面存在交叉，可能会导致项目管理和决策上产生混乱和冲突。另外，架构师能力的确认，也是一个难点，如何评定一个技术人员具备在某一个项目中承担架构师的能力，也是一个需要解决的问题。在组织层面上，架构师在组织中的隶属关系也需要研究，如果只是草率的将架构师分布在不同的事业部或中心，那么架构师也就失去了总览全局的能力，组织也就失去了设置架构师这一职能的初衷，但如果把架构师统一放在一个部门（如总师办），会不会又和科研一线的团队产生隔阂，或者让架构师的工作浮于表面？这些问题可能都需要实际运行进行验证。
在安全关键软件研发过程中，架构师具体要做什么
我们在安全关键领域设置架构师，由于该领域软件研发和课题任命具有其自身的特点，其工作与商用领域的架构师还有很大的不同的，具体体现在如下几个方面。
需求分析阶段
需求分析对于软件的重要性不言而喻，如今敏捷团队在项目实施过程中，之所以要求紧密的连接客户，在每一个冲刺完毕后就让客户对产品进行确认，目的其实也是为了保证自己理解的最终产品和客户需求是一致的。如今的互联网的APP为什么需要用户的反馈，为什么不停的迭代，目的之一也是为了自己的软件更加贴近用户的需求。即使在传统的瀑布流开发的模式中，需求分析也是软件开发流程中不可或缺的一步，有着严格的里程碑节点和评审机制，在很多软件企业中，需求分析是最终验收前的最后一次确认。所以说，需求分析不是不重要，而是太重要了。需求分析做的不对，或者不好，会导致团队期望中的产品与客户的需求产生偏差，交付的软件产品肯定达不到客户的预期。
在商用软件研发的团队中，大部分是没有软件总师这一职位的存在的，架构师一般会有很重的需求整理和分析的任务。在安全关键领域，软件的设计师任命一般会有软件总师或者对应的软件负责人存在，因此我们不能完全照搬商用软件开发中的架构师职责，而应该做出适当的变更。干过软件总师的人都知道，在项目的策划和需求分析阶段，软件总师的工作量是巨大的。那么应该如何协调软件总师（负责人）和架构师之间的权责，使其产生“1+1>2”的效果？最佳的处理方式肯定是各取所长，让熟悉业务背景和应用的软件总师负责对涉众的需求进行梳理和确认，而架构师此时应更偏重于技术选择、性能分析、技术风险分析等方面。（后边如果有兴趣，具体的工作分工可以专门写一篇）
软件设计阶段
软件设计阶段是架构师的作用体现的最明显的阶段。我们在安全关键领域设置架构师的最主要的目的就是优化组织的软件设计。软件架构师在设计阶段的工作包括但不限于以下几个方面：
- 辅助软件总师进行系统分解，梳理接口
- 配置项的实现方式，编程语言、设计约束、是否复用、如何分层、采用何种设计模式、是否使用框架等
- 指标和约束如何确认和验证
- 主持设计评审
编码阶段
编码阶段中，架构师将立足于自己在编码上的技术特长，致力于提升团队的代码质量，其工作主要包括：
- 编写框架代码，设计好各个模块的输入输出
- 主持代码评审，指出团队代码的不足与改进方向
- 主持静态测试与单元测试
- 设计集成规则，如果存在CI系统则应负责设计流水线
- 在所有代码模块中挑选可放入资产库的共用资产，并负责对它的维护
- 负责对历史遗留代码的重构和优化
结语
总的来说，在项目中设置架构师，应该有很多积极的意义，值得在实际项目中探索和应用。