设计准则笔记

一、编程思维

代码质量既是设计出来的，也是迭代优化出来的。学习设计模式最有效的办法就是：主动学习+刻意练习。好的设计从来不是看用的模式有多少，而是看如何合理利用模式的设计思想，以及如何利用模式解决真实的问题。如何正确学习设计模式：
摆正心态，正确分析设计模式可以解决和不能解决的问题。搞清楚设计模式的背景知识。具备高手独立思考的习惯。高手不拘泥于某一知识的高低贵贱，而是保持明智的判断，始终朝着坚定的目标前行。坚持。
要谨记：设计 ≠ 编码，愿望 ≠ 事实。学习设计模式的关键不在于你熟练掌握了多少设计模式，而在于能否真正灵活运用来解决更多复杂的现实问题。Unix 哲学是一套基于 Unix *** 作系统顶级开发者们的经验所提出的软件开发的准则和理念。Unix 哲学最早起源于 1978 年，是 Unix 设计者在一次关于如何设计简洁、高效的 *** 作系统服务接口中的思考总结。在随后的几十年间，它逐渐形成了自己独特的编程文化，并发展出了一套影响深远的设计哲学。Unix 设计哲学，主张组合设计，而不是单体设计；主张使用集体智慧，而不是某个人的特殊智慧。

Peter H. Salus 总结的三条原则:

编写可以做一件事并且做得很好的程序；

编写程序以协同工作；

编写程序来处理文本流，因为这是一个通用接口。

编程启示

保持简单清晰性，能提升代码质量。Unix 哲学中所说的保持简单性，并不单单是做到更少的代码量，更是在面对不同复杂度来源时也能始终保持简单清晰的指导原则。

借鉴组合理念，有效应对多变的需求。 Unix 哲学的组合思维：把软件设计成独立组件并能随意地组合，才能真正应对更多变化的需求。

解决思路：高内聚低耦合。

解耦。

模块化——可替换的一致性。

重拾数据思维，重构优化程序设计

Unix 哲学在出现之初便提出了“数据驱动编程”这样一个重要的编程理念。也就是说，在 Unix 的理念中，编程中重要的是数据结构，而不是算法

而 Unix 哲学提出的“数据驱动编程”会把代码和代码作用的数据结构分开，这样在改变程序的逻辑时，就只要编辑数据结构，而不需要修改代码了。

分层架构

流行的 MVC 分层架构

代码分层架构解决什么问题

如何快速拆解功能问题

如何提升代码的可扩展性------更容易做服务的横向扩展。

代码分层架构的优势

只用关注整个结构中的其中某一层的具体实现；

降低层与层之间的依赖；

很容易用新的实现来替换原有层次的实现；

有利于标准化的统一；

各层逻辑方便复用。

代码分层架构的劣势

开发成本变高

性能降低

代码复杂度增加

总结来说，代码分层架构是一种软件架构设计方法。

从软件的功能性需求角度看，分层是为了把较大的复杂问题拆分为多个较小的问题，在分散问题风险的同时，让问题更容易被解决，也就是我们常说的解耦。

从架构（非功能性需求）角度看，分层能提升代码可扩展性，帮助开发人员在相似的变化中修改代码。

其实，复杂的设计概念和简单的代码之间存在一种平衡，这就是分层架构。

代码分层架构设计的思维模型是简化思维，本质是抽象与拆解。代码分层架构设计的目的是将复杂问题拆分为更容易解决的小问题，降低实现难度。代码分层架构设计的原则和方法是通用方法，可以应用到其他需要分层设计的地方。

所以，分层架构从来不是目的，只是让我们的软件变得更好的其中一种思维方法而已。
软件开发中还有另一个难题是：业务到技术实现。 5 点建议：都是项目、盯紧目标、提前计划、有效沟通和交付结果。
都是项目。用项目的视角去处理问题或业务，会有两点好处：一是培养你从整体看问题的习惯；二是通过做计划，提高你的时间管理能力。当你用项目视角去重新看待这个问题时，你就会发现，优化只是一个手段和方法，在合适的阶段引入才是最重要的。盯紧目标。
负责到底是基本要求。 无论是写代码，还是做设计，只要是定下一个目标，就应该始终盯紧目标。不断调校是基于事实的合理改变。
提前计划。做事有计划是说，要在有限的条件下提前做好分析，并在一个相对固定的时间周期内合理安排任务。有效沟通。提问方式可以变为：“现在有一个问题需要解决，问题现象是 xxx，业务方的预期是 xxx，实际看到的是 xxx，不符合预期，从日志和报错看可能是 xxx 出问题了。由于 xxx 项目上线时间紧迫，急需解决，在线等。”交付结果。发布你的产品——具备闭环思维。

交付结果意味着你需要主动结束项目，包括结束确认、结束反馈、测试验证是否通过等，这和等待项目自动结束是完全不同的一种思考方式。
 
具备对象思维。
编程范式是一种根据编程语言的功能对编程语言进行分类的方法，它不针对具体的某种编程语言。编程范式与编程语言的关系可参考下图：面向对象编程是一种编程范式，是基于部分特定编程语言下的编程经验总结，代表了程序员在编码时应该如何构建和执行程序的一种方法集合。编程语言 ≠ 编程范式。面向对象编程优势
模块化更适合团队敏捷开发对象结构更能提升代码重用性、可读性。
面向对象有三大特性：封装、多态和继承。
解决了结构化语言面临的以下两大难题。第一个是全局变量问题。第二个是可重用性范围问题。
代码质量的好坏通常有三个维度：可读性、可测试性以及可维护性。组合和聚合思想让代码演进更重视组件化。组件就是封装了一个或多个程序代码的二进制文件，比如，Java 的 jar 包。

聚合关系表示整体由部分组成，但是整体和部分不是强依赖的，整体不存在了部分还是会存在。
组合关系和聚合不同，组合中整体和部分是强依赖的，整体不存在了部分也不存在了。

高效编程。高效编程除了需要提升细节上的编程效率外，还需要你能时常跳出细节思维，从整体的工作流程上去思考与改进。

高效编程应该具备下面五个要素：

高效编程 = 原则 * 工具 * 编码 * 反馈 * 迭代 

 建立原则。
第一条原则：问题到你为止。无论是不是你的问题，你都应该尝试去终结这个问题。
第二条原则：多读、多写代码。编程是一门重视实践的技术，你不写代码就一定不能提升对代码细节的感受力。方法一：多读别人的代码。方法二：多写自己的代码。
第三条原则：打破砂锅问到底。打磨工具。实践编码。及时反馈。迭代更新。
迭代有如下三个关键特征。
      每一个迭代都应该有输入、处理和输出。
      记录版本。
      不断更新。

编程不是一个体力活，编程应该是一个综合的脑力活：编程 = 写代码 + 讨论 + 学习 + 反思。

二、编程原则

在软件开发中，我们都学习过一些经典的设计原则，其中包括面向对象原则（SOLID）、简单原则（KISS）、单一原则（DRY）、最少原则（LoD）、分离原则（SoC）等。

单一原则   DRY（Don't Repeat Yourself），翻译成中文就是，不要重复你自己。
先可用，再重用。你应该先写出可以运行的代码，再考虑是否需要重用代码。

如果你还没有找到抽象的话，其实也没有关系，因为等到有更多的上下文时，还可以重构它。
所以说，要想不重复你自己，需要先不再随时关心代码重用性，保留适当的重复，等到真的重复时，再去抽象可复用的公共代码。

抓住上下文，适度设计。
当你想要扩展通用设计时，想想一年后这个项目是不是还存在。

坚持写易懂的代码。

第一，易懂的代码不是指容易、简单的代码。

第二，易懂的代码能借用语言特性来发挥优势。 

第三，易懂的代码需要遵从一定的代码规范。

第四，易懂的代码要能正确运行。

第五，始终牢记：易懂的代码不是你告诉计算机怎么做的答案，而是告诉另一个程序员你想要计算机做什么的意图。

宁可重复，也不要错误的抽象。不要为了抽象而创建抽象。

简单原则  KISS 原则（Keep It Simple and Stupid），翻译过来就是：保持简单，保持愚蠢。

在软件开发中，“简单”其实是最终的一个状态。

所以说，保持简单并不是只能做简单设计或简单编程，而是做设计或编程时要努力以最终产出简单为目标，过程可能非常复杂也没关系。

简单”是什么。

简单应该是坚持实践。

简单应该是尽量简单，但又不能太简单。换句话说，就是要管理合适的代码上下文环境，并且在边界范围内以“最少知识”的方式构建程序，满足要求即可，保持一定的克制。

简单应该是让别人理解代码逻辑时更简单。

how

要定期做 Code Review。 

要选择合适的编码规范。

要适时重构。

要有目标地逐渐优化。

​​​​​​​YAGNI 原则（You Ain't Gonna Need It），翻译过来就是：你不会需要它。换句话说，在软件开发中，它希望你不要写“将来可能需要，但现在却用不上”的代码。

​​​​​​​