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

一、前言

1.1、写的目的

      这一篇文章是想自己最近对于架构、模块、组件的优化的思考做个总结，不然没有思考总结就是体会不到软件其中的乐趣。不过自己的认识是比较粗鄙和浅显的，所以更多的是记录笔记和想法。

1.2、随思

    不过想着无论生活还是整个世界，对应到我们的代码框架中，都是随着我们的认识而不断去用架构去简化对其的认识，这样的做法是方便我们能够从中找到对应的模型和规律，用于去解决问题、创造新的东西。认识的深浅关心着我们的模型的完善程度，不要想着一次就能够完善的写出模型，或者说当前你认为比较完善的模型，可能在某个时间后它会重新迭代重构。

在认识不够清晰或者你自己没有找到一个认识的架构前，你更多依靠的是经验，这个在我们现实生活中也是比较常见的，一些行业本身的复杂度导致比较难去解构一个比较好的框架时，可能时越老越吃香。但不管如何，生活中每个面和点，人们都在创造新的模型去解决问题，而它的高级抽象慢慢应对的就是我们程序员需要去结合物理的时间自动化辅助人类更好、更快的认识世界。

二、基本名词的认识

1.1、软件架构

     软件架构又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

    软件架构工程师，根据软件产品需求分析及可行性分析，进行软件开发过程中所有流程与架构的设计、控制及管理，并解决架构中的技术问题的人员。

参考：系统架构师和软件架构师_你是一名软件架构师吗？_weixin_39949776的博客-CSDN博客

1.2、模块和组件

     组件(Component)和模块(Module)是一对容易混淆的名词，也常常被用来相互替换。两者是否有差异往往取决专业背景、所在领域、以及视角。

从设计上来看，组件强调复用，模块强调职责(内聚、分离)，或者说组件是达到可复用要求的模块。

把重复的代码提取出来合并成为一个个组件，组件最重要的就是重用（复用），位于框架最底层，其他功能都依赖于组件，可供不同功能使用，独立性强。

分属同一功能/业务的代码进行隔离（分装）成独立的模块，可以独立运行，以页面、功能或其他不同粒度划分程度不同的模块，位于业务框架层，模块间通过接口调用，目的是降低模块间的耦合，由之前的主应用与模块耦合，变为主应用与接口耦合，接口与模块耦合。

组件化可以提供代码的复用率，降低维护成本。

模块化可以提高团队的开发效率以及容错率，降低风险。因为每个模块都是独立的，一个模块的延期、bug不会对另一个模块产生影响。

参考：组件化和模块化有什么区别？ - 知乎

1.3、为什么要使用组件化和模块化？

3.1开发和调试效率高：随着功能越来越多，代码结构会越发复杂，要修改某一个小功能，可能要重新翻阅整个项目的代码，把所有相同的地方都修改一遍，重复劳动浪费时间和人力，效率低；使用组件化，每个相同的功能结构都调用同一个组件，只需要修改这个组件，即可全局修改。

3.2可维护性强：便于后期代码查找和维护。

3.3避免阻断：模块化是可以独立运行的，如果一个模块产生了bug，不会影响其他模块的调用。

3.4版本管理更容易：如果由多人协作开发，可以避免代码覆盖和冲突。

1.4、架构师的目的

对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。

重用：人们希望系统能够重用以前的代码和设计，从而提高开发效率。

扩展：人们希望在系统能够保持结构的稳定的前提下很容易地扩充功能和性能。

简洁：简洁是一种美，好的架构一定易于理解，易于学习，易于维护。

参考：软件架构——架构师的职责_byxdaz的博客-CSDN博客

1.4、软件工程师和软件架构工程师

     软件开发和软件架构之间有一条微妙的线。有人会说，这条线根本不存在，架构只是开发者设计过程的简单延伸。另外一部分人则说，这是一条巨大的鸿沟，只有少数出类拔萃的开发者才能跨越，这些开发者都认为你必须不断地向上抽象，避免陷入令人生厌的实现细节的泥沼。如果以务实的眼光看，那这两者之间必定存在某个平衡点，但这接着也提出了问题：如何从开发者变成架构师？

将软件架构从软件设计和开发中区分开来的关键因素包括：规模的上升、抽象层次的上升， 以及做出正确的设计决策带来的影响的上升等等。软件架构就在于能有一个全局视角、能具备更大的视野，理解软件系统作为一个整体是如何工作的。这些因素对区分软件开发和软件架构也许有帮助，但还是无法解释一些人如何从开发转到了架构。进一步地，对于如何识别哪些人将会成为出色的架构师，作为 HR 如何发现这些人，以及自己是不是一名架构师，上述定义也无能为力。

尽管经验是一个很好的衡量指标，但你应该看得更深。架构师是一个角色，而非级别。这是一个演进的过程，在这个过程中你会不断获得承担架构师角色所需的经验与自信。

三、软件架构做些什么事情

3.1、软件架构的定义

1. 非功能性需求的管理，软件项目经常将注意力放在用户的功能特性上，而很少问用户有什么非功能需求或系统性能要求。有时需求方会告诉我们说“系统必须足够快”，但这种表述太主观了。要满足非功能需求，那这些需要必须是具体的、可测量、可实现以及可测试的。

2.架构定义

弄清了非功能需求后，下一步就要思考如何定义架构，解决需求方提出的问题。 我们可以说每个软件系统都有架构，但不是每个软件系统都有现成的架构。这才是关键点。软件定义过程需要思考如何在给定的限制下满足提出的需求，进而解决问题。架构定义过程是在项目的技术方面引入结构、规范、原则和领导力的过程。定义架构软件架构师的工作，但从头设计一个软件系统与扩展一个现有系统还是有很大的差别。

3. 技术选型
技术选择通常是一个愉快的过程，但当考虑到成本、授权、供应商关系、技术策略 、兼容性、互操作性、支持、部署、升级策略、终端用户环境等问题时，挑战往往相当大。这些因素综合起来，经常会把一个简单的选择某些东西，例如设计一个功能丰富的客户端，变成一场噩梦。

接下来还有另一个问题：这些技术能否像期望的那样运行。

技术选型的本质管理风险：在复杂性或不确定性较高的地方减少引入风险，在可能带来收益的地方适当接受风险。

4. 架构评估

架构可以工作：满足非功能需求，为其他部分的代码提供了必要的 基础设施，为解决底层业务的问题提供了一个平台。

软件最大的问题之一就是复杂性和抽象，很难从 UML 图或代码去想象出软件运行时的特点。在软件开发的过程中，会采用多种测试技术确保交付的系统在上线之后能正常工作。为什么不对架构设计采用同样的方式呢？如果可以测试架构， 就可以证明该架构可以正常工作。这项工作做得越早，就越能减少项目失败的风险。而不是简单寄希望于它能正常工作。
5.架构协作

3.2、软件架构的交付

质量保障是架构师角色中的很大一部分工作，但并非仅仅是代码审核。例如，需要提供基准性能指标时，意味着需要引入标准和工作守则。从软件开发的角度讲，这包括编码标准、设计原则、源代码分析工具等。可以肯定地说，大部分项目的质量保障做的并不够。因此你需要辨别出哪些是重要的，并优先保证这些部分被执行。对我来说，一切对架构有重要影响的、对业务非常关键的、复杂的或能够可视化的东西都是重要的。这需要脚踏实地，意识到你无法保障所有方面，但实际做一些工作总比什么都不做好。

四、C现代编程笔记

嵌入式设备不得以牺牲可维护性来换取性能。

产品或者应用程序，如果跟不上变化的速度将无法生存，如果稍微停滞就会瞬间在竞争中落后。只要质量稍微下降或者响应速度变慢，操作上稍有不便就会立即与对手的竞争的落败，进而被市场淘汰。

C语言为了控制程序行为在函数群中不得不引入大量参数，所以通常使用的数据为全局变量，导致函数矩阵的函数耦合在一起很难单独测试。

只要能活用设计模式，就可以极大地改善程序结构，是程序各部分结构完全独立工作。

第三章

使用static修饰符是C开发常用的模块化方法。

通过将数据和处理成对分离并使用结构体和函数指针实现多态性，就将教研职责分离，而被分离出来的部分也可以作为组件被重复利用。同时重复编写相似的代码的情况也减少了，当需要修改代码时，修改点也会很少。

---多态性是指从调用者角度讲看对象会发现它们非常相似，难以区分，但是这些被调研对象内部处理实际上各不相同。

封装是将对象的状态和行为集中在一起，并规定其与外部的接口进行抽象化的过程。

c中没有提供访问控制功能，无法实现数据隐藏，但这也不是什么大问题，我们可以使用const修饰符外部修改内部数据。还可以通过命名时以下划线来回避不允许直接访问变量。

虚函数表指的是以static的方式，静态共享存储部分。但是会增加复杂度，可维护性程度。

第四章

状态模式，根据状态迁移图编写代码。

当c中出现goto时多与资源分配释放有关。

如何想方设法的实现，出贷模式形成一个模板，将资源的生命周期交由其他函数实现。

观察者模式，分离应用程序中固有处理，实现共同化，例如错误处理。观察者模式基本上都会通过回调来切断监控方与被监控方的依赖关系。

通过面向对象编程，可以将大的逻辑处理分割为更小的处理单元，使代码更加共通化。

责任链模式，每个处理对象依赖其后面一个对象

访问者模式，准备访问者，将访问者通过accept函数传递给校验器，根据校验器的类型调用者访问对应的函数，类似于多态了。

第五章，重构

1，函数提取，是设计模式的一种方式，观察者模式使用。

五、可以学习的书籍

1、架构师修炼之道

2、领域驱动设计

3、架构师书单 2nd Edition_江南白衣的博客-CSDN博客

4、10年资深架构师推荐21本技术好书_糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖的博客-CSDN博客

5、

成长篇
《异类》
一句话推荐：颠覆你对成功的认知，例如：什么才是赢在起跑线？为何现在的富人都是大约生于1955年左右？
《随机漫步的傻瓜》
一句话推荐：只要看这一本书，你就能免受所有鸡汤的毒害！
《一万小时天才理论》
一句话推荐：1万小时理论实践版，详细阐述了1万小时天才理论的3个关键点。
《情商》
一句话推荐：如果你认为你的老板还不如你聪明，那你需要好好看看这本书。

《优秀到不能被忽视》
一句话推荐：不管是工作还是爱好，要想成功的原则是什么？很简单，“做别人愿意买单的事情”！
《影响力大师》
一句话推荐：天天立flag，月月打自己的脸？不是你意志力不行，而是你方法不对，这本书可以给你一套完善、可操作的方法。（注：我以前读的版本叫《关键影响力》，新版改名叫《影响力大师》。）

技术篇
推荐技术书籍实际上是有一定局限性的，因为每个技术领域其实差异还是挺大的，就算都叫程序员，前端程序员、客户端程序员、后端程序员之间差异就很大；即使都是后端程序员，Linux开发和Windows开发所需要的技术也不一样。因此我提炼了一个通用的技术书籍学习路径，不同技术领域可以按照这个路径去拆解：

深度学习你的代码运行环境：例如Linux程序员一定要深入学习Linux和UNIX的操作系统，iOS程序员要深入学习iOS系统，前端程序员要深入学习浏览器原理，以此类推。
深入学习你的核心工具：例如Java程序员的核心工具是Java，嵌入式程序员是C，而DBA就不是学编程语言，而是学MySQL或者Oracle了。
深度学习领域基础知识：例如后端程序员的网络编程，前端程序员的动效知识，Android客户端程序员的渲染知识，以及所有程序员都要求的算法知识等。
广泛学习技术领域的通用成熟技术：例如前端程序员要学的React和Vue，Java程序员要学的Netty、Spring，互联网后端程序员的标配MySQL、Redis等。
下面我以Linux后端Java程序员为例，给你推荐相关技术书籍。
《UNIX编程艺术》
一句话推荐：经典书籍，结合UNIX的历史来讲UNIX设计哲学，改变你对编程的认知和理解。

《UNIX网络编程（卷1）》
一句话推荐：经典书籍，网络编程必读。书很厚，重点是前三部分，不需要一次全部读懂，先通读，后面经常参考并且加深理解。

《UNIX环境高级编程》
一句话推荐：经典书籍，Linux/UNIX C/C++程序员必读，就算是Java、PHP、Python等程序员也要通读一遍，了解系统底层能力有助于理解编程语言的各种实现。

《Linux系统编程》
一句话推荐：和《UNIX环境高级编程》类似，Linux平台可以看这本。
《TCP/IP详解（卷1）》
一句话推荐：经典书籍，全面介绍TCP/IP协议栈各种协议，重点看TCP和IP部分。
《算法之美》
一句话推荐：讲算法非常有趣的一本书，告诉你如何将算法应用于恋爱、生活、工作！
《算法设计与应用》
一句话推荐：将算法与实际应用结合起来，从应用引出算法然后进行算法推理，如果你数学很牛，可以挑战一下这本书；如果你数学很菜，那我更加推荐这本书，因为其中的算法原理和应用场景分析得清晰易懂。
《Java编程思想》
一句话推荐：经典书籍，全面介绍Java编程，入门必备。《深入理解Java虚拟机》
一句话推荐：全面理解Java虚拟机，原理介绍得深入浅出，很少有技术书籍我会优先推荐国内作者，而这本是我大力推荐的。

《C++ Primer》
一句话推荐：经典书籍，全面介绍C++编程。当年我看了很多C++书籍都不得要领，看了这本后豁然开朗。

业务篇
不管是普通程序员还是架构师，实践工作中都需要有一定的业务理解能力，而架构师的业务理解能力要求更高。理解业务一方面有利于更好地设计有针对性的架构或者方案，另外一方面也可以防止被产品经理坑 ：

《增长黑客》
一句话推荐：肖恩·埃利斯和摩根·布朗的这本书理论体系完整，既给出了很多实践技巧，又总结了很多经验和需要避开的陷阱。

《需求》
一句话推荐：如何理解用户需求、如何满足用户需求、同样产品为何有的公司失败而有的公司取得了巨大成功？这本书让我茅塞顿开，建议技术同学都推荐这本书给你们的产品经理。

《淘宝产品十年事》
一句话推荐：这本书总结了淘宝10多年发展过程中产品遇到的各种坑和挑战，让你明白“罗马不是一天建成的”，产品也是逐步演化的（这也是我的“架构设计三原则”中的“演化原则”）。

《定位》
一句话推荐：告诉你如何做业务战略规划，有些偏重理论，架构师需要学习，程序员可以先放一边。

《宝洁制胜战略》
一句话推荐：结合宝洁的经验，提出了一套完善的战略规划和落地方法，理论与实践兼备，架构师必备，拿着这套方法论，就可以PK你的老板了。