文章目录
前言
博主只是个小白，初次看《代码大全》这本书的时候，其实体会不深，没怎么看的进去，很多笔记都是复制下来就放在那了，没怎么去总结过，所以这次打算把之前记下来的笔记用自己的语言再总结一次，看完这篇笔记，我相信大家都会对编程会有全面的理解。
引言
这本书很厚，内容很多，但我们废话不多说，我把当前我认为值得跟大家分享的写下来。我会从三个方面去跟大家讲这本书，分别是编程前要做的准备，编程时应该注意的事项和编程后的调试维护。
一.编程前应该要做的准备
完成一个软件的过程大体分5步，分别是需求分析，软件设计，编码，测试代码，后期维护。这个5个步骤中，后期维护往往占据大头。如果前期的需求分析和软件设计没做好，后面维护的时候就有得哭了。而需求分析和软件设计正是我们编程前应该要做的准备。
需求分析
为什么要有明确的需求？
明确的需求有助于确保是用户(而不是程序员)驾驭系统的功能。如果需求明确，那么用户就可以自行评审，并进行核准。否则，程序员就常常会在编程期间自行决定需求。明确的需求免得你去猜测用户想要的是什么。明确的需求还有助于避免争论。在开始编程之前，先把系统的范围(scope)确定下来。如果你和另外一个程序员对于“程序应该做什么”意见不一致，你们可以查看书面的需求，以解决分歧。
大家也知道的，本来功能都做到一半了，忽然跟我说想变更一下功能，严重一点的代码又得设计一遍，想死的心都有了，但没办法，客户是上帝，我们要冷静，冷静。所以明确的需求分析可以确保我们后面不会被需求变更搞心态，但很多时候客户一开始也不知道他们想要什么功能，所以需求变更是少不了的。跟客户沟通这些活一般都是产品经理去干的，我们好好安心敲代码就好啦。
如果一定要我们去做需求分析的话，一定要从客户的角度去思考问题，去代入进去，因为有一些客户不懂技术，你也要跟他们说清楚，不要来一些压根做不到的需求，一开始也不用面面俱到，这是很难的，编码时也得跟客户沟通，做好变更需求的准备。总而言之，大家一定要多开口沟通，这很重要！
说了这么多，好像都是做别人项目的需求分析，那如果是自己的项目呢？自己的项目？我不知道其他人，我反正直接跳到编码阶段了，也可能是我没做过那种大型复杂的项目，平时自己做的，也是大概知道要做什么，然后都是边敲代码的时候边想了，这样子说是不是会有点误人子弟，不过没关系，刚开始的时候大家以熟悉代码语法为主，暂时先不用想那么多。
软件设计
好的软件设计能让我们后期维护时，不用那么费力。我一开始也不理解，本来直接几步完成的事，为什么非要得去设计这么多接口和抽象，那是因为刚开始时大家压根都没去想过后面维护的事。
“软件设计”一词意味着去构思、 创造或发明一套方案，把一份计算机软件的规格说明书要求转变为可实际运行的软件。设计就是把需求分析和编码调试连在一起的活动。好的高层次设计能提供一个可以稳妥容纳多个较低层次设计的结构。好的设计对于小型项目非常有用，对于大型项目就更是不可或缺。
软件的首要技术使命：管理复杂度
当项目确由技术因素导致失败时，其原因通常就是失控的复杂度。有关的软件变得极端复杂，让人无法知道它究竟是做什么的。当没人知道对一处代码的改动会对其他代码带来什么影响时，项目也就快停止进展了。通常高复杂度主要源于下面三种根源：
- 用复杂的方法解决简单的问题
- 用简单但错误的方法解决复杂的问题
- 用不恰当的复杂方法解决复杂的问题
正如Dijkstra 所指出的，现代的软件本身就很复杂，无论你多努力，最终都会与存于现实世界问题本身的某种程度的复杂性不期而遇。这就意味着要用下面这两种方法来管理复杂度:
- 把任何人在同一时间需要处理的本质复杂度的量减到最少
- 不要让偶然性(accidental)的复杂度无谓地快速增长
说人话就是能简单的去实现的东西，不要去做复杂了，1+1明明可以直接等于2，你非要写个证明。
做软件设计得一步步来，书里面是分为5层的。
第1层：软件系统
第一个层次就是整个系统。有的程序员直接从系统层次就开始设计类，但是往往先从子系统或者包(package)这些类的更高组织层次来思考会更有益处。
第2层：分解为子系统或包
在这一层次上设计的主要成果是识别出所有的主要子系统。这些子系统可能会很大，比如说数据库、用户界面、业务规则、命令解释器、报表引擎等。这一层的主要设计活动就是确定如何把程序分为主要的子系统，并定义清楚允许各子系统如何使用其他子系统。对于任何至少需要几周时间才能完成的项目，在这一层次上进行划分通常都是必需的。
在这一层次中，有一点特别重要，即不同子系统之间相互通信的规则。如果所有的子系统都能同其他子系统通信，你就完全失去了把它们分开所带来的好处。应该通过限制子系统之间的通信来让每个子系统更有存在意义。
第3层：分解为类
在这一层次上的设计包括识别出系统中所有的类。例如，数据库接口子系统可能会被进一步划分成数据访问类，持久化框架类以及数据库元数据。 当定义子系统中的类时，也就同时定义了这些类与系统的其余部分打交道的细节。尤其是要确定好类的接口。总的来说，这一层的主要设计任务是把所有的子系统进行适当的分解，并确保分解出的细节都恰到好处，能够用单个的类实现。
类与对象的比较
面向对象设计的一个核心概念就是对象(object) 与类(class)的区分。对象是指运行期间在程序中实际存在的具体实体(entity), 而类是指在程序源码中存在的静态事物。对象是动态的，它拥有你在程序运行期间所能得到的具体的值和属性。例如，你可以定义一个名为Person的类,它具有姓名、年龄、性别等属性。在程序运行期间，你可以有Uzi、Faker、 Theshy 等对象一它们是类的具体实例。 如果你熟悉数据库术语的话，类与对象的关系就如同“模式(schema)" 与“实例(instance)” 一样。你可以把类看做是蛋糕模具，而把对象看做是蛋糕。
第4层：分解成子程序
这一层的设计包括把每个类细分为子程序。在第3层中定义出的类接口已经定义了其中一些子程序，而第4层的设计将细化出类的私用(private) 子程序。当你查看类里面子程序的细节时，就会发现很多子程序都很简单，但也有些子程序是由更多层次化组织的子程序所组成的，这就需要更多的设计工作了。
第5层：子程序内部的设计
在子程序层次上进行设计就是为每个子程序布置详细的功能。子程序内部的设计工作通常是由负责该子程序的开发人员来完成的。这里的设计工作包括编写伪代码、选择算法、组织子程序内部的代码块，以及用编程语言编写代码。这一层的设计工作总是需要做的，尽管有时做得很不在意或者很差劲，有时则是经过深思熟虑而出色完成的。
我们平时说的架构师，就是干这方面的内容。软件架构(software architecture)是软件设计的高层部分，是用于支撑更细节的设计的框架。 架构也称为“系统架构/system architecture". “高层设计/high-level design”或“顶层设计/top Jevel design".通常会用一份独立的文档描述架构，这份文档称为“架构规格书/architeture specifction”" 或者“顶层设计"。有些人对“架构”和“高层设计”加以区分——架构指的是适用于整个系统范围的设计约束，而高层设计指的是适用于子系统层次或多个类的层次上的设计约束（但不是整个系统范围的设计）。
书里面架构的典型组成部分
- 程序组织
- 主要的类
- 数据设计
- 业务规则
- 用户界面设计
- 资源管理
- 安全性
- 性能
- 可伸缩性
- 互用性
- 国际化/本地化
- 输入输出
- 错误处理
- 容错性
- 架构的可行性
- 过度工程
- 关于“买”还是“造”的决策
- 关于复用的决策
- 变更策略
- 架构的总体质量
这方面我了解的也不多，感兴趣的可以自己去查点资料。
二.编程时应该要注意的事项
内容同样很多，我也只把我遇到的和觉得有用的写下来。
类
类是由一组数据和子程序构成的集合，这些数据和子程序共同拥有一组内聚的、明确定义的职责。类也可以只是由一组子程序构成的集合，这些子程序提供一组内聚的服务，哪怕其中并未涉及共用的数据。成为高效程序员的一个关键就在于，当你开发程序任一部分的代码时，都能安全地忽视程序中尽可能多的其余部分。而类就是实现这一目标的首要工具。
类一般分俩种，实体类和功能类，实体类不用多说，就是我们在现实世界抽象出来的属性集合，拿来承载信息用的。功能类就是专门用来实现业务逻辑的。
说到类，又离不开面向对象。平时网上看的资料都是说面向对象的特性分别是封装，继承，多态，但在书里多了一个抽象。
面向对象的要点是辨识现实世界中的对象(object, 物体)以及人造的(synthetic)对象。使用对象进行设计的步骤是:
- 辨识对象及其属性(方法(method) 和数据(data) )
- 确定可以对各个对象进行的操作。
- 确定各个对象能对其他对象进行的操作。
- 确定对象的哪些部分对其他对象可见一哪些部分可以是公用(public)的，哪些部分应该是私用(private)的。
- 定义每个对象的公开接口(public interface)
创建高质量的类，第一步，可能也是最重要的一步， 就是创建一个好的接口。这也包括了创建一个可以通过接口来展现的合理的抽象，并确保细节仍被隐藏在抽象背后。有时候一个类里面方法太多，看代码时看的眼花缭乱的，这时我们可以创建个接口或者抽象，只提供实现，不暴露细节，这样就方便很多，因为大多时候我们看方法名就能知道这个方法是干嘛的了。而且接口和抽象也是实现多态必不可少的一步，这是我们解耦大利器。
抽象
抽象是一种能让你在关注某一概念的同时可以放心地忽略其中一些细节的能力一在不同的层次处理 不同的细节。任何时候当你在对一个聚合物品( ggregate)工作时，你就是在用抽象了。当你把一个东西称为“房子”而不是由玻璃、木材和钉子构成的组合体时，你就是在用抽象了。当你把一组房屋称为“城镇”时，你还是在使用抽象。
基类也是一种抽象， 它使你能集中精力关注一组派 生类所具有的共同特性，并在基类的层次上忽略各个具体派生类的细节。一个好的接口也是一-种抽象，它能让你关注于接口本身而不是类的内部工作方式。一个设计良好的子程序接口也在较低的层次上提供了同样的好处，而设计良好的包(package) 和子系统的接口则在更高的层次上提供了同样的好处。
以复杂度的观点看，抽象的主要好处就在于它使你能忽略无关的细节。大多数现实世界中的物体(object， 对象)都已经是某种抽象了。正如上面所提到的，房屋是门、窗、墙、线路、管道、隔板等物体及其特定的组织方式所形成的抽象。同样，门是-块长方形材料加上合叶和把手以及-种特定的组织方式的抽象。而门把手又是铜、镍、铁、钢等的一种特定形式的抽象。
我对抽象的理解也是一知半解，总的来说，就是你有一组相似特征的对象时，可以使用抽象来创建一个通用的模板。比如说，你要处理文件，文件格式有很多种，创建了很多处理不同文件的类，比如说WordFileParser，PdfFileParser等文件类，然后你发现他们内部的方法返回值其实都差不多，只是实现逻辑不同，比如说获得文件本身，长度等，你调用他们的时候，每次都得传一个不同的文件类，还得为他们设置不同的构造函数，这是我们抽象出一个FileParser类，只需传FileParser过去，到时要用哪个再强转一下就好了，这个例子可能不是很贴切。反正你一定要理解类所实现的抽象是什么，必须非常仔细地理解类的接口应该捕捉的抽象到底是哪一个。
封装
封装是一个比抽象更强的概念。抽象通过提供一个可以让你忽略实现细节的模型来管理复杂度，而封装则强制阻止你看到细节一即便你想这么做。这两个概念之所以相关，是因为没有封装时，抽象往往很容易被打破。依我的经验，要么就是封装与抽象两者皆有，要么就是两者皆失。除此之外没有其他可能。尽可能地限制类和成员的可访问性
- 不要公开暴露成员数据
- 避免把私用的实现细节放入类的接口中
- 不要对类的使用者做出任何假设
- 不要因为一个子程序里仅使用公用子程序，就把它归入公开接口
- 让阅读代码比编写代码更方便
- 要格外警惕从语义上破坏封装性
- 留意过于紧密的耦合关系
继承
继承的概念是说一个类是另一个类的一种特化(specialization)。继承的目的在于，通过“定义能为两个或更多个派生类提供共有元素的基类”的方式写出更精简的代码。其中的共有元素可以是子程序接口、内部实现、数据成员或数据类型等。继承能把这些共有的元素集中在一个基类中，从而有助于避免在多处出现重复的代码和数据。跟继续息息相关的是包含，包含是个非常简单的概念它表示一个类含有一个基本数据元素或对象。与包含相比，关于继承的论述要多得多，这是因为继承需要更多的技巧而且更容易出错，而不是因为继承要比包含更好。包含才是面向对象编程中的主力技术。
多态
简单来说，多态性就是同一个接口，不同的表现形态。多态性使得代码更加灵活和可扩展。
- 多态性在调用方法时，实际调用的是对象实际类型的重写方法，而不是引用类型的声明方法。
- 多态性只能用于方法，不能用于属性。
- 多态性要求子类和父类之间存在继承关系，或者类实现了相同的接口。
子程序
子程序也就是方法，写方法是为了让我们的代码看起来更加易懂和能复用，如果不怎么用方法，代码全写一堆，逻辑很难理的清，该抽出来时就抽出来，那我们要注意什么呢
- 起好名字，名字非常重要，一般是动宾结构，比如我们常用的getXXX和setXXX
- 参数不能过多
- 方法体里面代码行数也不要太多，50~150行是最佳的，短点的也可以，怎么看着好怎么来
- 能private就不要public
变量
变量应该注意的事项
- 在声明变量的时候初始化
- 在靠近变量第一次使用的位置初始化它
- 理想情况下，在靠近第一次使用变量的位置声明和定义该变量
- 在可能的情况下使用final或者const
- 尽可能缩短变量的”存活“时间
命名
我们自己平时练手的项目可能没怎么注意过，因为都是写给我们自己看的，能看懂就行。但出来后，往往都是一个团队开发项目，你写的代码别人也得能看懂才行，这时命名规范就非常重要了，命名规范一般每个公司的大差不差，小驼峰大驼峰那些就不说了，说说如何起一个好名。
命名时最重要的考虑事项是，该名字要完全、准确地描述出该变量所代表的事物。获得好名字的一种实用技巧就是用文字表达变量所代表的是什么。通常，对变量的描述就是最佳的变量名。这种名字很容易阅读，因为其中并不包含晦涩的缩写，同时也没有歧义。因为它是对该事物的完整描述，因此不会和其他事物混淆。另外，由于这一名字与所表达的概念相似，因此也很容易记忆。
类名和变量名一般都是名词短语，方法名一般都是动宾结构。还有不要用生僻单词，刚开始时确实很困难，这得靠积累，敲多了会发现来来去去都是那些单词。
语句
写代码时尽量组织直线型代码，必须有明确顺序的语句，不要把不相关的代码都凑一堆，适当的可以用空格隔开。
写if语句时首先写正常代码路径，再处理不常见情况。循环语句的for，while，foreach循环什么情况下该去用哪个就不说了，这个大家久而久之就会用了。
判断语句有时如果过长的话，我们可以抽出来用一个boolean变量，还有循环语句不易嵌套过深，3层就差不多了。
三.编程后的调试维护
写程序我相信大家都会写，但写出一个好程序就很难了。因为你压根不知道别人会怎么用你的软件，所以总会有很多莫名其妙的bug。有一句玩笑话是这么说的，10行代码实现功能，100行代码防沙雕。所以说说如何去调试代码。
调试
调试包括了寻找缺陷和修正缺陷。
解决bug其实很简单，但绝大部分人90%的时间都是用来寻找bug和去理解bug。那如何去找呢？请把print语句随机地散布在程序中。检查这些语句的输出来确定bug到底在哪里。如果通过print语句还是不能找到缺陷，那么就在程序中修改点什么，直到有些东西好像能干活了。通过输出语句我们先把出bug的范围锁定下来，看看在哪个类的哪个方法里，然后在里面多打点print语句，再详细定位到哪一块代码，很多时候的bug要么是越界要么是空指针造成的，看是看不出来的，这时候就得慢慢的去debug。
有时候不理解的话，可以专门去写一些测试代码验证一下自己的猜想。如果一直想不通的话，也不要钻牛角尖，去问问别人或者去外面走走放松一下大脑，有时候就是你走进死胡同了，过阵子回来一看就会发现突然豁然开朗了。
修改bug的时候，动手之前要先理解问题，然后记得要保存原代码，免得改着改着找不回来了。
维护
维护往往占据软件周期的大头，后面有不停要加的新功能，添加新功能的时候也得要兼容老功能。维护的时候就能体会到前面的软件设计的重要性了，面向对象设计模式中就有个原则叫开闭原则，指的是对拓展开放，对修改关闭。我们在添加新功能的时候最好只要添加新的类就行，不要去修改原来的老代码，不然很容易牵一发而动全身，到时有的玩了。
代码中也不要出现神秘数字，你敲这段代码的时候你还能知道什么意思，过阵子可能就忘了，导致维护起来很困难，最好把他们都放在一个自己建的常量类或者资源文件里，这样子到时要改什么配置的话也不用一个个去改，改一个就行了。
有时候你维护着代码，维护着就会发现整个程序都变得很臃肿，发现很多原因
- 代码重复。
- 子程序太长。
- 循环太长或者嵌套太深。
- 类的内聚性太差。
- 类的接口的抽象层次不一致。
- 参数表中参数太多。
- 类的内部修改往往局限于某个部分。
- 需要对多个类进行并行修改。
- 对继承体系的并行修改。
- 需要对多个case语句进行并行修改。
- 相关的数据项只是被放在-起，没有组织到类中。
- 成员函数更多地使用了其他类的功能，而非自身类的。
- 过于依赖基本数据类型。
- 一个类不做什么事。
- 一连串传递流浪数据的子程序。
- 中间人对象什么也不干。
- 某个类同其他类关系过于密切。
- 子程序的命名太差。
- 数据成员被设置为公用。
- 派生类仅仅使用了基类的一小部分成员函数。
- 用注释来掩饰拙劣的代码。
- 使用了全局变量。
- 在子程序调用前使用设置代码,
- 调用后使用收尾代码。
- 程序包含的某些代码似乎在将来某个时候才会被用到。
这时候就得考虑重构代码了，重构就是在不改变软件外部行为的前提下，对其内部结构进行改变，使之更容易理解并便于修改。一个好的程序都是在不断的优化，修改下完成的。修改本身并不是什么了不得的好事，但如果是程序员深思熟虑而为之，且遵循规范恰如其分，那么在不断的维护下，这样的修改必将成为代码质量稳步提升之关键，且能避免如今随处可见的代码因质量不断下降而最终灭亡的趋势。
按照重构的规模，我们可以将重构大致分为大规模高层次的重构和小规模低层次的重构。大规模高层次重构包括对代码分层、模块化、解耦、梳理类之间的交互关系、抽象复用组件等等。这部分工作利用的更多的是比较抽象、比较顶层的设计思想、原则、模式。小规模低层次的重构包括规范命名、注释、修正函数参数过多、消除超大类、提取重复代码等编程细节问题，主要是针对类、函数级别的重构。小规模低层次的重构更多的是利用编码规范这一理论知识。那种顶层的抽象和设计思想不是我们小白该考虑的事情，我说说我们新手应该要改什么：
- 改善命名，这也是我一直强调的
- 消除重复代码，有时候你敲的时候直接C过去没什么感觉，但多了就会看着很臃肿，该抽时就抽出来
- 简化复杂结构，方法和类如果太复杂，试去拆分更小的方法和类
这些都是最基础的重构了，大家感兴趣的也可以去找找其它资料，接下来引用一下书里的话——不要把重构当做先写后改的代名词，重构最大的问题在于被滥用。程序员们有时会说自己是在重构，而实际上他们所完成的工作仅仅是对无法运行的代码修修补补，希望能让程序跑起来。重构的含义是在不影响程序行为的前提下改进可运行的代码。那些修补破烂代码的程序员们不是在重构，而是在拼凑代码(hacking)。
开发阶段的重构是提升程序质量的最佳时机,因为你可以立刻让刚刚产生的改变梦想变成现实。请珍惜这些开发阶段的天赐良机！
总结
这是博主的第一篇博客，感觉写了一坨屎。。。不过我相信计算机专业的同学应该都有过写博客的想法，我大一时就有了，一直拖，拖到现在快毕业了终于磨出来了，写这篇博客，也是对自己所学知识的一个体会总结，希望这篇文章能帮助大家如何去编写一个好程序有大概的了解，知道自己要去干嘛和注意什么事项。
最后，祝愿大家能在编程这条路坚持下来，坚持不下来也没事，这时候就得借鉴一下我舍友一直在说的话了——人生是旷野，而不是轨道。
标签：重构,代码,子系统,抽象,小白该,设计,子程序,大全 From： https://blog.csdn.net/weixin_63421392/article/details/139528856