- 点击跳转=>GameFramework文档系列（四）- 事件订阅
- 点击跳转=>保姆式Cocos合成大西瓜案例
- 点击跳转=>养不起真猫，就用代码吸猫-Unity粒子实现画猫咪
- 点击跳转=>Unity粒子特效系列-龙卷风预制体做好了，unitypackage包直接用！
- 点击跳转=>姐姐喊我解锁套娃新技能：FairyGUI在Unity中实现List嵌套List/立体画廊等，玩出花儿来
- 点击跳转=>Unity新手必备5款宝藏插件–价值上千元白嫖最新版
- 点击跳转=>爆肝万字C#基础入门大总结【建议收藏】
- 点击跳转=>【万字】修行Android Studio技巧到出神入化，快速涨薪【建议收藏】
- 点击跳转=>Android修行手册之从头到尾学Kotlin【全】
- 点击跳转=>熬夜再战Android从青铜到王者-开发效率插件篇
本文约8.3千字，新手阅读需要17分钟，复习需要9分钟 【收藏随时查阅不再迷路】
👉关于作者
众所周知，人生是一个漫长的流程，不断克服困难，不断反思前进的过程。在这个过程中会产生很多对于人生的质疑和思考，于是我决定将自己的思考，经验和故事全部分享出来，以此寻找共鸣 ！！！
专注于Android/Unity和各种游戏开发技巧，以及各种资源分享（网站、工具、素材、源码、游戏等）
有什么需要欢迎私我，交流群让学习不再孤单。
👉前提
注意：文章内容有些是书本原句，有些是感悟
确实正如书中所言，书中多偏向理论层面的内容，实际操作或方法少之又少。
讲真，看完后总觉得书中什么都没说，但是又感觉什么都说了。有一种灵魂离体不受掌控又能感受到的其妙体验。
额，就挺怪怪的
👉实践过程
在我心中程序员分为三个层次：普通程序员、工程师和架构师。
普通程序员是编写代码的人，只要能让程序跑起来，符合业务逻辑，就可以成为普通程序员。
时间久了，一些程序员发现单纯的编写代码还远远不够，这个世界是变化的，物与物之间总有着千丝万缕的关系。一旦需求增多，开始扩展，原来写的程序可能需要更多的时间来维护代码。这就需要程序设计的更加易读，易维护易扩展，才能满足千变万化的场景。这类程序员开始有了工匠精神，开始将程序设计的更加优美和便捷，代码就像搭建积木一样，模块化一点点拼接就成了较完成的产品。
到这还没完，人类总是想要探索更深的海洋。现实中凡事都有好有坏，解决问题的方法不是万能的，总会有新的方法解决旧的问题，从而又诞生出新的问题，就像蓝银草一样，野火烧不尽，春风吹又生。这时候有些工程师站起来了，他们总是探索新的方案，引领着行业前进，这就是架构师。
带着观点和问题我们进入该书的海洋。
观点：无论是微观世界的代码,还是宏观层面的标构,无论是三种编程范式还是微服务架构,它们都在解决一个问题一一分离控制和逻辑。所谓控制就是对程序流转的与业务逻辑无关的代码或系统的控制(如多线程、异步、服务发现、部署、弹性伸缩等),所谓逻辑则是实实在在的业务逻辑,是解决用户问题的逻辑。控制和逻辑构成了整体的软件复杂度,有效地分离控制和逻辑会让你的系统得到最大的简化。
问题：如果你要成为一名架构师,你需要明确地区分几组词语(如何区分它们正是留给你的问题),否则你不可能成为一名合格的工程师或架构师。这几组词语是简单vs.简陋、平衡vs.妄华、迭代Vs.半成品。如果你不能很清楚地定义出其中的区别,那么你将很难做出正确的决定,也就不可有成为一名优秀的工程师或架构师。
按照Bob大叔的说法，所谓架构就是“用最小的人力成本来满足构建和维护系统需求”的设计行为。
就像盖房子一样，其组成结构一目了然【水泥，砖块等】，并且遵循现实世界的自然规律，比如重力。而软件架构确是没有固定的展现形式，甚至可以做到千人千面。
所以开发产品走的快的唯一方法就是先走好【所谓好也是具有针对性的，没有任何一款架构符合所有的业务场景】。但有时候好架构需要的成本可能太高，这时候就回头看看选择差的架构和返工重来带来的成本孰轻孰重。
文中有一个很有意思的举例：让一个上世纪的人穿越到现代和让现代的人穿越到上世纪，上他们敲写程序，可能需要一定的时间适应新的欢迎，但要不了多久他们就能正常工作了。
再举个例子，我们学习编程语言的时候，当理解了一门后再学习其他语言，是不是只用通读下基本就能上手了。
虽然这几十年硬件设备的提升可能大的难以想象，但软件结构形式【逻辑的组合】基本没有变化。仔细联想下，现在我们用的很多语言都是继承了上个世纪的思想，虽然我们一直在更新，但本质上可以说我们和上世纪没区别。
😜结构和设计是什么？
设计可以说是架构的组成部分，而架构又是经过设计所产生的。他们之间没有明确的区分，甚至都没有区别。
拿造车举例：生产汽车包括座位，外壳，发动机，空调，油箱，车胎等等大模块，他们可以称为架构的组成部分。但是在详细的往里看，座位的设计【颜色，样式，尺寸】，车胎的设计【半径，胎纹】等等这些都是经过相当详细的设计而产生的，甚至详细到了毫米的单位上。
所以，他们是密不可分的，你中有我，我中有你。
现在我们开发产品，总是想着快速上线，总是“欺骗”自己上线后再想重构的事情，但事实并非如此，一旦上线，频繁的版本迭代根本没时间重构，再加上同类产品的竞争追赶，更加没时间想这些了。
最终的结果就是，招人越来越多，产品越做越臃肿，直至承受不住。
这一点小空是感同身受的，已经不知道这么干了多少回了。
随着编程领域的不断发展，出现了编程范式，共有三种【相继在1960年左右提出】，相信未来短期内也不太可能出现新的。
结构化编程：对程序控制权的直接转移进行了限制和规范。
面向对象编程：对程序控制权的间接转移进行了限制和规范。
函数式编程：对程序中的赋值进行了限制和规范。
总的来说，这么多年，开发工具不断变化，但是软件编程的核心一直不变，都是有顺序结构、分支结构、循环结构和间接转移这几块组成的，缺一不可。
😜SOLID原则
她不是一个单一的原则，而是多个原则的简称。
SRP：单一职责原则
通俗点就是一个类尽量负责一个职责，避免需求改变的时候带动其他职责功能故障。
OCP：开闭原则
其核心是必须允许新增代码就能修改系统，而不是只靠修改原来的代码。也就是对扩展开放，对修改关闭。
LSP：里氏替换原则
想要系统的组成部分可以替换，这些就必须遵守同一个规则或约束。比如类B继承类A，类A有某个方法，现在需要扩展类A再增加个方法，我们可以增加个类C继承类A，类A增加函数，然后类B继承类C，这样既有了之前的功能也有了新的功能，反之亦然。
所以，利用巧妙的方法子类可以扩展父类的功能，但不要改变父类原有的功能。
ISP：接口隔离原则
避免在设计过程中不必要的依赖。比如接口A中有5个方法，类B实现接口A只用到了前两种方法，类C实现接口A，只用了后三种方法，这种情况，类C和类B都多了不必要的方法，很累赘，所以接口A可分为接口A1和A2，A1接口是类B的两个方法，A2是类C实现的方法，互不干扰。
DIP：依赖反转原则
提出结构性的代码不应依赖具体逻辑代码，应该是相反的，逻辑代码依赖结构代码。比如类A依赖类B，现在将类A的依赖改为类C，这就必须要修改类A了。这很不合适。所以，我们将类A改为接口，类B和类C实现类A接口，后续逻辑在使用的时候定义参数是类A接口，具体实现可以是类B和类C。
REP：复用/发布等同原则
按照小空的理解就是同一个组件内的资源，文档，类声明等等内容，要保持一致，及时更新。比如Java一个较小的工具组件，可能有几个类【平时写代码的时候应该都有文档注释】，当你更新的时候，文档注释里写的版本号或者说明，这几个类都要更新一下。防止别人调用你的时候因为版本问题出现差错。
CCP：共同闭包原则
这个理解起来还简单一些，就是解决某个需求的相关功能代码应该放在同一个组件中。比如有个类A，此类里面有对文件的读写判断等操作，又有了图片的放大缩小模糊等功能代码。这就有点不伦不类。他们应该分在不同的小组件才合适。
CRP：共同复用原则
文章提到的是：不要强迫一个组件的用户依赖他们不需要的东西。就是告诉我们类的依赖要分开，别一环套一环，类A依赖类B，类B依赖类C，类C依赖类D，整的隔着套娃呢。如果这几个类又在不同的组件中的话，一修改那得当场炸裂。
😜无依赖环原则
这是个有头有尾的连环依赖：A依赖类B，类B依赖类C，类C依赖类D，类D依赖类A。这种情况应该很明确ABCD他们应该是同一个大组件内，而不能分开在不同的组件，否则不同的组件又是不同的人负责，你加班加点干完后，第二天一来又不能运行了，调来调去发现同事把你依赖的组件修改了。我靠，小空直接TM想干架。【抱歉，说粗话了】
因为小空实实在在经历过，就沟通着呢，下一秒对方就改了，也没和你说，你浪费不少时间排查原因发现原来是别人的工作导致。…………
😜稳定依赖原则
我们用公式来作为直观的指标
稳定性=出向依赖/(入向依赖+出向依赖)
根据字面意思我们可以看出来入向依赖是该组件被其他组件依赖的数量（比如组件A被组件B和组件C所依赖），而出向依赖则是相反的，指的是该组件依赖的其他组件数量（比如组件A依赖组件B和组件C）。
稳定性的范围是【0-1】，越小越稳定。
所以任何一个我们预期会变更的组件都不应该被一个难以修改的组件所依赖，否则这个多变的组件也将会变得非常难以被修改。
千万不要钻牛角尖，想要所有的组件都稳定那是不可能的，这就需要我们设计的架构稳稳当当分清楚谁需要稳定谁可以不稳定。
😜稳定抽象原则
这一原则学的时候没绕过弯来，所以小空没有什么举例证明，所以直接引用下阿里云文章的一段话：
一个组件的抽象化程度应该与其稳定性保持一致。为了防止高阶架构设计和高阶策略难以修改，通常抽象出稳定的接口、抽象类为单独的组件，让具体实现的组件依赖于接口组件，这样它的稳定性就不会影响它的扩展性。
小空特别喜欢其中一部分：软件架构师必须是一线程序员，千万不要摆脱代码空空而谈，就像脱离了人民群众的领导，你不亲身体会其中设计带来的麻烦和痛苦，你怎么寻找到正确的方向？怎么能够引导团队最大化生产力不断前进呢？
中间这部分小空读了，说实在的，自己本事没修炼到家，这部分理论性较强读完感觉没什么要点，所以在这也就直接省略这部分了。不过我还是列举出他们的章节名称，有兴趣的自己看原著吧。
👉什么是软件结构👉独立性👉划分边界👉边界剖析👉策略与层次👉业务逻辑👉尖叫的软件架构👉整洁架构👉展示器和谦卑对象👉不完全边界👉层次与边界👉Main组件👉服务：宏观与微观👉测试边界👉整洁的嵌入式架构
😜数据库只是实现细节
作者在书中说了一段故事：他和同事争论在项目中要不要使用数据库，而争论的问题点不是该技术对项目的影响，而是市面上人们都在用，有些客户要求用，所以要增加，但你问他为什么又不知道为什么用。
不错，数据库确实稳健又优雅，但不管他多么的精巧和便捷，她只是个技术，只是解决某个问题的方案，不是必然存在的。
😜Web是实现细节
开篇作者就说出了真相：开始Web是简单的展示，资源的计算再服务端，随着时间的推移，人们将很多计算又放到了Web端，又随着技术发展，屁颠屁颠的将计算量又挪回服务端，来来回回，一声叹息。
总结一段话就是：业务要尽力和UI解耦
😜框架是实现细节
框架流行是一件非常好的事，能为社区带来很好的活跃性，这点不可否认，你帮我，我帮你，快快乐乐甜甜蜜蜜。
但请记住不要过分依赖框架，在使用框架之前先慢慢的从非核心业务开始，直到熟悉之后。如果你上来就大换血，很容易造成不可想象的错误。仔细想想框架作者和框架使用者是单方面的关系，就是使用者受作者限制，但作者不受使用者限制。框架作者写的框架其一是根据自己的实际开发经验其二是技术栈，针对他自己来说可能很合适，但是不同的人不同的项目遇到不同的事情，框架不一定全部受用，重复造轮子也是这个原因。
所以，框架，可用，但不可过分依赖。
😜结尾
剩下的章节是作者的小举例和真实故事，这个不太好总结，有兴趣的去书中看原始真解吧。
本书内容学习到此结束了，虽然学到了很多名词和设计方式，但千万不要被约束了。放空心态，大胆设想，小心求证。
👉其他
📢作者：小空和小芝中的小空
📢转载说明-务必注明来源：https://zhima.blog.csdn.net/
📢这位道友请留步??，我观你气度不凡，谈吐间隐隐有王者霸气💚，日后定有一番大作为📝！！！旁边有点赞👍收藏🌟今日传你，点了吧，未来你成功??，我分文不取，若不成功??，也好回来找我。