C语言代码质量与架构调整（四）

1、前言

 “软件架构师”这个名词也不知是什么时候进入我的脑中的，不过一直就很疑惑，总觉得和软件的Team Leader之间有些纠缠不清。不过以我的观点来看，软件架构师除了没有行政上的职责以外，与Team Leader也并无二致了，也就是一个软件团队的核心设计者和决策人。从业经历大致划分为3个阶段。

参与一个软件系统的架构（contributing to the architecture of a software system）和亲自设计一个软件的架构之间有很大不同。 持续精进的技能、知识和跨多领域的经验，成就了软件架构师的角色。

跨越软件工程师和软件架构师的主动性在于自己，而首先要做的，就是理解自己目前的经验 所处的层次。

参考来源：

怎么成为一个软件架构师_chui88的博客-CSDN博客

1.1、第一阶段是新手期

这个阶段的典型特征是容易被新技术的华丽外表所迷惑。当在网上看到一种新技术的介绍或者心得，立即产生了大量肾上腺素的分泌，干什么都想用一用，如果这时有人跟他说你的这项工作用这个不合适的话，要是性子急的人估计就直接开始骂娘了。

新手时期的程序员对需求和应用环境的掌控能力还不强，但却往往信心爆棚地认为自己写的代码有多么优雅高效。当问题出现时，大多数人的反应就是：“怎么可能！在我的机器上运行的好好的！”。不管看了多少书，学习了多么高效的算法，实际的工作中需求和环境始终是变化万端的。

新手期程序员的不成熟还体现在团队表现上，当一个问题提交给新手，当跟踪别人的代码段时，经常会丢手不管，独善其身在团队开发中是最要不得的想法。

1.2、第二阶段是中级程序员阶段

这个阶段的程序员对技术、和工具的选择已经审慎了很多，可以根据具体的需求来选择需要采用的技术，可以写出详细的需求调研报告并提出设计方案，优点、缺点分析得清晰明了。在应用层面也有较强的全局理解力，在团队中也具有相当的协作能力，因此具备较强的解决问题的能力。

中期的程序员虽然在应用层面上已经相当严谨，但在系统层面的掌控力却并不强。应用系统也并非独善其身，她和网络环境、使用方法、硬件环境、操作系统、地点、时间等等诸多因素有着千丝万缕的联系。

1.3、第三阶段是高级程序员/分析师/架构师阶段

进入这个阶段的前提是多年的工作经验，广阔的知识面和对系统底层到高层的全面认识，已经使其进入了无语言无工具的层次。也就是能任何清楚地感知每种编程语言的优劣、使用范围、编码禁忌，对一个大型工程能有最全面的了解，在选择语言和确定技术方案的时候不会被自己对语言或技术工具的偏好（或者根本已经无所偏好）所影响，真正明白了其实别管是神马语言、神马技术，归根到底咱们的对象还不是CPU、内存、硬盘和网络，该做的事情一件都不能少，所谓的技术框架是对初级程序员用的，真正高级了不研究个清楚透彻都不敢让你进来。即使对同一种语言，在不同的操作系统中，如Visual C++和Unix C、AIX  XLC、GNU G++等等的区别，以及不同版本之间的区别也了如指掌。这个阶段很难达到是由于对操作系统层面的清晰了解，相信一个初级程序员一路走来，大部分工作都是在Team Leader的规范和引导下完成的，每人都必须做好自己的工作，虽然在应用层面必须顾全大局，但系统层面的问题相对就难以接触了。如果不是对技术有着强烈的渴求和一定的综合能力，系统层面的工作经验将很难与你有缘。

高级阶段一定需要有团队的开发和管理经验，软件团队的每个人对语言、业务、能力的理解都不一样，交流方式也有别，同时他们操作着相同的系统和资源，如果Team Leader不做好规划，后果肯定可想而知。丰富的经验和敏锐的触觉神经足以判断出团队成员的编码风格和技术选择偏好，能以足够的经验和理由说服其抛弃自己的感情偏好，从而很好地完成自己的工作。这种能力有点类似于行政的管理，但实际上却是有明显的不同的，这种管理基于的是实际的丰富经验和充足的理由，绝对不可以将行政管理中的排队观念带入，如果2个人意见相左，就必须争论，争不下去了回家想清楚理由再争，甚至直到时间来证明一切，不能说这次你听我的，下次我听你的，技术工作是绝对的，最好的、最适合需求的方案永远只有一个，如果你觉得“都可以”，只能说对行业和需求还没有吃透。

高级程序员是经常会对需求说“No”的人，对行业的深入认识和对系统及应用全局的把握能力使他具有真正指导用户的能力，规范用户的工作、思想并用计算机这个工具真正对行业产生引领作用。高级架构师能深入认识管理和技术的关系，管理上出现的问题一定要在管理上解决，工作经验不多的用户或者程序员往往会把管理上产生的问题抛给软件系统，导致系统越来越复杂，维护成本迅速增长，而管理上的问题却依然存在。

1.4、最后，技术和社会是紧密联系在一起的。

社会的进步发展决定了需求和技术的发展，一个对技术发展有着敏锐感觉的架构师必须对社会有着深刻的认识。一个良好的团队必须有新老交替才能不断进步，老人要舍得带新人。

2、如何成为架构师

成为架构师需要怎么做，各项能力的要求展开讲，系统架构相关的知识和经验。

3、系统架构相关的知识和经验

关于架构，框架和设计模式三者的说明，架构是一个范畴最大的概念，是最高层次的设计，一个架构设计中可能会用到多个框架和多个设计模式。

框架是针对共性抽象出来的半成品，这里面可能包含着多个设计模式；

设计模式就是解决单一问题的设计思路和解决方法。

架构
架构是一种代码的管理方案，用来提高代码的可读性和可维护性，MVC，MVP，MVVM，或者自己对自己项目代码的管理方案都可以称为架构
框架
框架是一种业务处理方案，是帮你写好的东西，已经完成部分业务，继承到自己项目中完成项目中部分功能，像okHttp,Retrofit,Glide等第三方库可以成为框架
设计模式
设计模式是功能的实现方案，是能达到某种目的的一种代码的写法，以后也会对各种设计模式进行详细的讲解

3.1、架构

　　架构即软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件体系结构是构建计算机软件实践的基础，简单来说，软件架构是一个系统的草图，是一种设计方案，将客户的不同需求抽象成为抽象组件，各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

　　在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

1.1、鼓励团队参与架构设计

架构评估、架构质量属性

3.2、框架

　　框架即软件框架，通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。

　　框架的功能类似于基础设施，与具体的软件应用无关，是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，提供并实现最为基础的软件架构和体系。软件开发者通常依据特定的框架实现更为复杂的商业运用和业务逻辑。这样的软件应用可以在支持同一种框架的软件系统中运行。

　　简而言之，框架就是制定一套规范或者规则（思想），大家（程序员）在该规范或者规则（思想）下工作，不同领域的软件项目有着不同的框架类型。框架不是现成可用的应用系统。而是一个半成品，提供了诸多服务，开发人员进行二次开发，实现具体功能的应用系统。

3.3、组件

稍有规模的软件系统一定会被拆分成很多组件，

组件内聚三大原则：

1、复用发布等同原则

2、共同封闭原则

3、共同复用原则

组件耦合三大原则：

1、无循环依赖原则

2、稳定依赖原则

3、稳定抽象原则

3.4、设计模式

　  设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案，设计模式特指软件“设计”层次上的问题。

　　设计模式并不直接用来完成代码的编写，而是描述在各种不同情况下，要怎么解决问题的一种方案。它是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，它强调的是一个设计问题的解决方法。

　　面向对象设计模式通常以类别或对象来描述其中的关系和相互作用，但不涉及用来完成应用程序的特定类别或对象。设计模式能使不稳定依赖于相对稳定、具体依赖于相对抽象，避免会引起麻烦的紧耦合，以增强软件设计面对并适应变化的能力。

参考：
架构、框架和设计模式 - 简书

MVC，MVP和MVVM架构解析_mvc、mvp、mvvm的应用场景_浮空over的博客-CSDN博客

MVC、MVP、MVVM三种区别及适用场合_VIctor_Ye的博客-CSDN博客_mvvm的适用范围

架构、框架和设计模式（1）架构 | iherr的博客

 

3.5、领域驱动设计

领域是一个组织所做的事情及包含的一切，从领域出发，分析领域内模型及其关系，进而进行设计软件系统的方法。

通过业务分析，识别出实体对象，然后通过相关的业务逻辑设计实体的属性和方法。

4、读书

软件架构：架构模式、特征及实践指南，演进式架构，架构之美，google软件工程，从程序员到架构师，软件架构，架构师应该知道的37件事，从零开始学架构

4.1《架构师修炼之道》

四条原则：HART，以人为本（设计的本质事社交），推迟决策（推迟不确定的决策），善于借鉴（所有设计都是在已有设计基础上的重新设计和调整创新），化虚为实（让想法具体化、有形化，以便于沟通交流）。

4.2《从零开始学架构》

1、合理的方案应该怎么做

备选方案，3~5个为主；备选方案的差异比较明显；备选方案的技术不要局限于已经熟悉的技术

2、合理的方案应该避免怎么做

设计最优秀的方案；只做一个方案；备选方案过于详细

3、如何评选最佳方案

复杂度的来源---性能、可用性、硬件成本、项目投入、复杂度、安全性、扩展性；合适原则和简单原则、演化原则（防止过度设计）

5、写作、沟通表达、培训

设计图，它不是简单的供你欣赏，他其实是架构师，产品经理，开发工程师，测试工程师等各种角色之间进行沟通的语言，沟通的一个桥梁，让整个团队更能有效的协调工作。

设计图不单单是架构师要掌握的，在一个产品的开发过程中，任何一个环节，任何一个角色都可以通过掌握不同的设计图来完成沟通的。

常见的展示方法

除了线框图外，制作原型、编写文档、开展实验、比较数据、讲故事

背景图、启动计划书（5w2h）、模块分解图、时序图

想要做”架构师“，一定要会画设计图_互扯程序的博客-CSDN博客_架构设计图

6、参考

若想进阶为软件架构师，这10本书必须读！_p312011150的博客-CSDN博客_软件架构书籍

[译] 你是软件架构师吗？（InfoQ，2010）