01-代码整洁之道3天版课件

计算机专业必读书籍计算机专业要读哪些书籍呢?下面是店铺精心为您整理的计算机专业必读书籍，希望您喜欢!一些经典的计算机书籍算法导论(第2版)代码大全(第2版)C++ Primer中文版(第4版)设计模式：可复用面向对象软件的基础浪潮之巅Java编程思想(第4版)Java核心技术卷1：基础知识Java核心技术卷2：高级特性人月神话Linux内核编程C程序设计语言(第2版新版)黑客与画家：硅谷创业之父Paul Graham文集编程之美：微软技术面试心得代码之美软件随想录：程序员部落酋长Joel谈软件架构之美国外计算机科学经典教材：Unix & Linux大学教程深入理解计算机系统(原书第2版)UNIX网络编程卷1：套接字联网APIUNIX网络编程卷2：进程间通信自动机理论、语言和计算导论软件架构的艺术Effective C++中文版Effective Java中文版(第2版)PHP & MySQL Web数据库应用开发指南(第2版)PHP经典实例(第2版)C++ 编程思想第1卷C++ 编程思想第2卷两卷合订本Linux内核设计的艺术：图解Linux操作系统架构设计与实现原理数据库系统导论(原书第8版)Python参考手册(第4版)Python灰帽子提高C++性能的编程技术从网管员到CTO：网络设备配置与管理实战详解深入理解计算机系统(修订版)UNIX编程艺术深入理解Java虚拟机:JVM高级特性与最佳实践框架程序设计代码整洁之道编程珠玑(第2版)、编程珠玑(续)大话设计模式C#开发宝典深入理解Linux内核(第3版)UNIX环境高级编程 (第2版)WCF服务编程：.NET开发者决战SOA的制胜利剑(第3版)现代编译原理:C语言描述 (虎书)高级编译器设计与实现 (鲸书)编译原理(第2版)(龙书)Windows核心编程 (第5版)C++标准程序库：自修教程与参考手册设计原本：计算机科学巨匠Frederick P.Brooks的思考软件框架设计的艺术计算机专业人士必读好书(30本经典)1. 《代码大全》史蒂夫·迈克康奈尔推荐数：1684“优秀的编程实践的百科全书，《代码大全》注重个人技术，其中所有东西加起来，就是我们本能所说的“编写整洁的代码”。

《架构整洁之道》读书笔记1. 设计与架构软件架构的终极⽬标是，⽤最⼩的⼈⼒成本来满⾜构建和维护该系统的需求。

⼀个软件架构的优劣，可以⽤它满⾜⽤户需求所需要的成本来衡量。

如果该成本很低，且在系统的⽣命周期内始终很低，那么这个系统的设计就是优良的。

反之，就是不好的设计。

胡乱编写代码的⼯作速度，其实⽐循规蹈矩更慢。

要想跑得快，先要跑得稳。

2. 两个价值维度⾏为价值：程序按照需求⽂档要求的⽅式⼯作架构价值：软件的“软”，即软件的灵活性艾森豪威尔矩阵重要且紧急重要不紧急不重要但紧急不重要且不紧急紧急的事情往往没那么重要，⽽重要的事情似乎永远也排不上优先级。

第⼀个价值维度：系统⾏为，是紧急的，但是并不总是特别重要。

第⼆个价值维度：系统架构，是重要的，但是并不总是特别紧急。

应有的排序：重要且紧急重要不紧急不重要但紧急不重要且不紧急常犯的错误：将第三优先级的事情提到第⼀优先级去做。

导致重要的事情被忽略。

平衡系统架构的重要性与功能的紧急程度，是软件研发⼈员⾃⼰的职责。

建议：为好的软件架构⽽持续⽃争研发团队必须从公司长远利益出发，与其他部门抗争，公司内部的抗争本来就是⽆⽌境的。

软件的可维护性需要由你来保护，这是你的职责，公司雇你的很⼤⼀部分原因就是需要有⼈来做这件事。

3. 编程范式编程范式指的是程序的编写模式。

⼀共只有三种编程范式，⽽且未来⼏乎不可能再出现新的（理由是，编程范式都是增加限制，Bob⼤叔的理解）。

⼀本谈软件架构的书，为什么要设计编程范式呢？Bob⼤叔如是说：多态是我们跨越架构边界的⼿段，函数式编程是我们规范和限制数据存放位置与访问权限的⼿段，结构化编程则是各模块的算法实现的基础。

这和软件架构的三⼤关注重点不谋⽽合：功能性、组件独⽴性、数据管理。

结构化编程可推导性：可以⽤代码将⼀些已证明可⽤的结构串联起来，只要证明额外的代码是正确的，就可以推导出整个程序的正确性goto语句的某些⽤法会导致某个模块⽆法被递归拆分成更⼩的、可证明的单元。

《代码整洁之道》总结和笔记前⾔《代码整洁之道》在业内有很⾼的知名度，被诸多前辈推荐给后来者阅读。

本书以循序渐进改造⼀个⼩程序的⽅式，演⽰了⼀个程序可能的各种设计（在代码层⾯）。

⼿把⼿教你该怎么设计代码，为何要这样设计，这样设计的好处是什么。

通过⼀周的阅读，总结了如下要点。

⼀函数所有的编程都是从HellWorld这个⼩函数开始的，学会设计函数⾮常重要1. 函数要短。

短才⽅便阅读、维护和设计。

(每个⼈都经历过读不懂⾃⼰代码的尴尬)2. 函数只做⼀件事。

依照单⼀职责原则设计函数。

⼀个函数可以:流程控制，逻辑判断，改变变量状态，以及做运算，或者调⽤多个下⼀抽象级的函数。

3. 函数分解成多个抽象层级设计，⾼层函数只调⽤下次层函数，呈树状图，层层封装。

4. 函数不应该有标识参数(除了作为API的函数)，这意味着函数有⾄少两种执⾏⽅式，违反了第2条原则。

⽽且明显能拆成多个⼩函数。

5. 函数参数越少越好有，多个参数应该封装成⼀个整体传⼊的。

如果逻辑上不是⼀个整体，则函数肯定能被拆成多个⼩函数然后被分别调⽤。

第4条标识参数可以封装进整体传⼊函数，⽽不是直接作为函数的参数6. 函数真的最好只做⼀件事，不要为了⼀时⽅便顺⼿加⼏⾏代码。

如登录验证时，函数⽤来验证username和password，在验证之后顺便给⽤户初始化些其他东西。

会导致这个函数在其他时候⽆法验证⽤户信息。

7. 底层函数不应该改变参数状态，如果想改变某类的状态，就把该函数加⼊该类，让它⾃⼰调⽤函数。

如：把改变类x的状态的函数调⽤addFooter(x)，改为x.addFooter()。

8. 函数不要返回错误码，这需要你有错误码的枚举类，并且违反了开放封闭原则（你需要加⼊新错误码来扩展新错误），直接抛出异常就好了。

（可以通过继承⽗异常来扩展）。

但是实际上错误码的应⽤不⽐异常少，⽽且异常也会导致代码的臃肿。

9. 函数名称应该描述清楚函数作⽤，避免频繁去看⽂档，这对于短⼩的函数来说不难办到，如果很难命名可能需要思考函数是否有依照以上原则设计(你⼀个函数可能做了很多事情)。

《架构整洁之道》组件设计的原则,一共包括六个原则。

1.引言1.1 概述概述部分的内容可以描述文章的背景和意义，介绍本文将要讨论的主题以及所提供的组件设计原则的重要性。

可以参考以下内容进行撰写：概述：在软件开发领域，良好的组件设计是确保系统可靠性和可维护性的重要因素之一。

组件设计的质量直接影响着软件系统的稳定性和扩展性。

然而，随着软件规模的增长和功能的复杂化，开发者面临着越来越多的挑战，如何进行有效的组件设计成为了一个关键问题。

本文将引导读者了解组件设计的原则，帮助开发者提升系统的质量和可维护性。

通过遵循这些原则，开发者可以创建出易于理解、灵活性强、可重用的组件，从而提高软件系统的整体质量。

本文将介绍六个重要的组件设计原则，这些原则是在架构整洁领域被广泛应用和验证过的。

每个原则都有其独特的特点和作用，从不同角度出发，帮助我们在设计组件时做出明智的决策。

无论是正在从事软件开发的初级工程师还是资深的架构师，都可以从本文中获得宝贵的经验和知识。

对于初学者来说，了解这些组件设计原则可以帮助他们构建出更好的软件系统。

对于经验丰富的开发者来说，本文提供的原则可以作为复习和提醒，帮助他们保持对组件设计的敏锐意识。

总之，本文旨在探索架构整洁的道路，为读者提供宝贵的组件设计原则，以帮助他们构建出高质量、可维护的软件系统。

下面我们将详细介绍这六个重要的组件设计原则，以及它们的具体实践方法。

请继续阅读下一部分，以了解组件设计的核心原则。

文章1.2 文章结构部分的内容:本文将分为三个主要部分进行阐述：引言、正文和结论。

引言部分将概述文章的主题和目的，为读者提供对于“架构整洁之道-组件设计的原则”这一主题的一个整体认识。

在引言的概述中，将对“架构整洁”和“组件设计”的概念进行解释和界定，并简要介绍文章的结构安排。

接着，将明确阐明本文的目的，即通过介绍组件设计的原则，帮助读者了解在软件开发过程中如何在架构层面上做到整洁和易于维护。

代码整洁之道【笔记】一、整洁代码A.混乱的代价1.有些团队在项目初期进展迅速，但有那么一两年的时间却慢去蜗行。

对代码的每次修改都影响到其他两三处代码2.花时间保持代码整洁不但有关效率，还有关生存3.程序员遵从不了解混乱风险经理的意愿，也是不专业的做法4.Bjarne Stroustrup，C++发明者：我喜欢优雅和高效的代码。

代码逻辑应该直接了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。

整洁的代码只做好一件事。

5.Grady Booch，《面向分析与设计》：整洁的代码简单直接。

整洁的代码如同优美的散文。

整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直接了当的控制语句。

6.Dave Thomas，OTI公司创始人：整洁的代码应可由作者之外的开发者阅读和增补。

它应有单元测试和验收测试。

它使用有意义的命名。

它只提供一种而非多种做一件事的途径。

它只有尽量少的依赖关系，而且要明确地定义和提供清晰、尽量少的API。

代码应通过其字面表达含义，因为不同的语言导致并非所有必须信息均可通过代码自身清晰表达。

7.Michael Feathers，《修改代码的艺术》：我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。

整洁的代码总是看起来像是某位特别在意它的人写的。

几乎没有改进的余地。

代码作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码——全心投入的某人留下的代码。

8.Ron Jeffries，《极限编程实施》：简单代码，依其重要顺序：能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽量少的实体，比如类、方法、函数等9.Ward Cunningham，Wiki发明者：如果每个例程都让你感到深合已意，那就是整洁代码。

如果代码让编程语言看起来像是专为解决那个问题而存在，就可以称之为漂亮的代码。

《架构整洁之道》读书笔记（三）1、整洁架构常见系统架构，六边形架构（端⼝与适配器架构）、DCI架构、BCE架构。

共同设计⽬标：按照不同关注点对软件进⾏切割。

核⼼点：分层 + 依赖规则分析：1、分层：关注点分离思想分层：这些架构都会将软件切割成不同的层，⾄少有⼀个层是只包含软件的业务逻辑的，⽤户接⼝、系统接⼝属于其他层。

2、依赖规则代码依赖只能使由外向内，内层结构的代码不能包含有任何外层结构的信息1、越靠近圆⼼即越是稳定的，即代表⾼层策略，越外围表⽰是低层组件,2、依赖⽅式：从图中也可以看出，低层组件依赖⾼层组件(策略)3、业务实体层：包含业务实体，即应⽤的业务对象，封装最通⽤最⾼层的业务逻辑(单独某个业务实体的逻辑)，它不应该受外界影响4、⽤户⽤例层：实现⽤户某个⽤例场景的业务逻辑封装，是对业务实体的组装、封装5、接⼝适配层：⽬的是进⾏数据的交换，包含有⽹关、控制器、展⽰器，如：实体层和⽤户实例层使⽤的数据转化成为持久层能使⽤的数据，⽐如数据库6、框架与驱动层：包含数据库、⽤户界⾯、web框架等每⼀种架构⼀定能在写系统的业务逻辑的时候有以下特征：1、与框架分离：系统架构不依赖于某个功能丰富的框架中的某个函数，框架被当作⼯具使⽤，不需要让让系统来适应框架。

2、可测试性：系统的业务逻辑可以脱离UI、数据库、Web服务及其他外部元素来测试。

3、与UI分离：UI必须能⾮常容易独⽴地修改。

⽽不能在改变UI的同时需要改变系统其他部分。

⽐如当把系统的UI从Web UI改成控制台UI，你并不需要改变任何业务逻辑的代码。

4、与数据库分离：能很⽅便地在Oracle，SQL Server，Mongo DB，BigTable，CouchDB或者其他数据库中进⾏切换和改变。

业务逻辑决不能依赖这些数据库。

个⼈思考：⽬前公司⼀直使⽤某种数据库，这个在⼀定时间内改变的可能性⽐较⼩！5、与外部结构分离：系统的业务逻辑并不需要知道任何外部的结构。