网站开发哪种框架,旅游公司网站难做吗,zara网站建设需求分析,黑龙江公司网站建设概述
对前面的内容的回顾#xff0c;温故而知新#xff0c;包括#xff1a;面向对象、设计原则、规范与重构三个模块的内容。 1.代码质量评判标准
如何评价代码质量的高低#xff1f;
代码质量的评价具有很强的主观性#xff0c;描述代码质量的词汇也有很多#xff0c…概述
对前面的内容的回顾温故而知新包括面向对象、设计原则、规范与重构三个模块的内容。 1.代码质量评判标准
如何评价代码质量的高低
代码质量的评价具有很强的主观性描述代码质量的词汇也有很多比如可读性、可维护性、灵活、优雅、简洁。这些词汇是从不同的维度去评价代码质量的。它们之间有相互作用并不是独立的比如代码的可读性好、可扩展性好就意味着代码的可维护性好。代码质量高低是一个综合各种因素得到的结论。我们并不能通过单一维度去评价一段代码的好坏。
最常用的评价标准有哪几个
最常用到几个评判代码质量的标准有可维护性、可读性、可扩展性、灵活性、简洁性、可复用性、可测试性。其中可维护性、可读性、可扩展性又是提到最多、最重要的三个评价标准。
如何才能写出高质量的代码
要写出高质量的代码我们就需要掌握一些更加细化、更加能落地的编程方法论这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。
面向对象
1.面向对象概述
现在主流的编程范式或者编程风格有三种它们分别是面向过程、面向对象和函数式编程。面向对象这种编程风格又是这其中最主流的。现在比较流行的编程语言大部分是面向对象编程语言。大部分项目也是基于面向对象编程风格开发的。面向对象编程因为其具有丰富的特性封装、抽象、继承、多态可以实现很多复杂的设计思路是很多设计原则、设计模式编码实现的基础。
2.面向对象四大特性
封装也叫作信息隐藏和数据访问保护。类通过暴露有限的访问接口授权外部仅能通过类提供的方法来访问内部信息或者数据。它需要编程语言提供权限访问控制语法来支持例如 Java 中的 private、protected、public 关键字。封装特性存在的意义一方面是保护数据不被随意修改提高代码的可维护性另一方面是仅暴露有效的必要接口提高类的易用性。
如果说封装是讲的是如何隐藏信息那抽象就是将如何隐藏方法的具体实现让使用者只需要关心方法提供了哪些功能不需要知道这些功能是如何实现的。抽象可以通过接口或者抽象类来实现。抽象存在的意义一方面是修改实现类不需要改变定义另一方面它也是处理复杂系统的有效手段能有效地过滤不必要关注的信息。
继承用来表示 is-a 的关系分为两种模式单根继承和多继承。单继承表示一个子类只能继承一个父类多继承表示一个子类可以继承多个父类。为了实现继承这个特性编程语言需要提供特殊的语法机制来支持。继承主要用来解决代码复用的问题。
多态是指子类替换父类在实际的代码运行过程中调用子类的方法实现。多态这种特性也需要编程语言提供特殊的语法机制来实现比如继承、接口类、duck-typing。多态可以提高代码的可扩展性和复用性是很多设计模式、设计原则、编程技巧大代码实现基础。
3.面向对象VS面向过程
面向对象相比面向过程编程的优势
对于大规模复杂程序的开发程序处理流程并非单一的一条主线而是错综复杂的网状结构。面向对象编程比起面向过程编程更能应对这种复杂类型的程序开发。面向对象编程相比面向过程编程具有更加丰富的特性封装、抽象、继承、多态。利用这些特性编写出来的代码更加易扩展、易维护、易复用。从编程语言跟机器打交道方式的演进规律中可以总结出面向对象编程比起面向过程编程更加人性化、更加高级、更加智能。
面向对象编程一般使用面向对象编程语言来进行但是不用面向对象编程语言我们照样可以进行面向对象编程。反过来讲即便我们使用面向对象编程语言写出来的代码也不一定是面向对象编程风格的也可能是面向过程编程风格的。
面向对象和面向过程两种编程风格不是完全对立的。在用面向对象编程语言开发的软件中面向过程风格的代码并不少见甚至在一些标准的开发库如 JDK、Apache Commons、Google Guava中也有很多面向过程风格的代码。
不管使用面向过程还是面向对象来写代码最终的目的还是写出易维护、易读、易复用、易扩展的高质量代码。只要我们能避免面向过程编程风格的一些弊端控制好它的副作用在掌控范围内为我们所用我们就大可不用避讳在面向对象编程中书写面向过程风格的代码。
4.面向对象分析、设计与编程
面向对象分析OOA、面向对象设计OOD、面向对象编程OOP是面向对象开发的三个主要环节。
面向对象分析就是要搞清楚做什么面向对象设计就是要搞清楚怎么做面向对象编程就是将分析和设计的结果翻译成代码的过程
需求分析的过程实际上是一个不断迭代优化的过程。我们不要视图一下就给出一个完美的解决方案而是先给出一个粗糙的、基础的方案有一个迭代的基础然后再慢慢优化。这样一个思考过程能让我们摆脱无从下手的窘境。
面向对象设计和实现要做的事情就是把合适的代码放到合适的类中。至于到底选择哪种划分方法判定的标准是让代码尽量满足 “松耦合、高内聚”、单一职责、对扩展开发对修改关闭等我们之前讲到的各种设计思想和原则尽量地做到代码可复用、易读、易扩展、易维护。
面向对象分析的产出是详细的需求描述。面向对象设计的产出是类。在面向对象设计这一环节我们将需求转化为具体的类的设计。这个环节的工作可以拆分为下面四个部分。
划分职责进而识别出有哪些类。 根据需求描述我们把其中涉及的功能点一个个罗列出来然后再去看哪些功能点职责相近操作同样的属性可否归为同一个类。定义类的属性和方法。 识别出需求描述中的动词作为候选方法再进一步过滤筛选出真正的方法。把功能点涉及的名词作为候选属性然后再同样进行过滤筛选。定义类与类之间的交互关系 UML 统一建模语言定义了六种类之间的关系。分别是泛华、实现、关联、组合、聚合、依赖。我们从更加贴近编程的角度对类与类之间的关系做了调整保留了四个关系泛华、实现、组合、依赖。将类组装起来并提供执行入口 将所有的类组装在一起提供一个执行入口。这个入口可能是一个 main() 函数也可能是一个组合外部用的 API 接口。通过这个入口可以出发整个代码跑起来。
5.接口VS抽象类
抽象类不允许被实例化只能被继承。它可以包含属性和方法。方法既可以包含代码实现也可以不包含代码实现。不包含代码实现的方法叫做抽象方法。子类继承父类必须实现抽象类中的所有抽象方法。
接口不能包含属性Java 可以定义静态常量只能申明方法方法不能包含代码实现Java8 以后可以有默认实现。类实现接口的时候必须实现接口中申明的所有方法。
抽象类是对成员变量和方法的抽象是一种 is-a 的关系是为了解决代码复用问题。接口仅仅是对方法的抽象是一种 has-a 的关系表示具有一组行为特性是为了解决解耦问题隔离接口和具体的实现提高代码的扩展性。
什么实时使用抽象类什么时候使用接口
实际上判断的标准很简单。如果要表示 is-a 的关系并且是为了解决代码复用问题就用抽象类。如果要表示一种 has-a 的关系并且是为了解决抽象而非代码复用的问题那我们就用接口。
6.基于接口而非实现编程
应用这条原则可以将接口和实现相分离封装不稳定的实现暴露稳定的接口。上游系统面向接口而非实现编程不依赖不稳定的实现细节这样当实现发生变化的时候上游系统的代码基本上不需要做改动以此来降低耦合性提高扩展性。
实际上“基于接口而非实现编程” 这条原则的另一个表述方式是“基于抽象而非实现编程”。后者的表述方式其实更能体现这条设计原则的设计初衷。在软件开发中最大的挑战之一就是需求的不断变化这也是考验代码设计好坏的一个标准。
越抽象、越顶层、越脱离具体某一实现的设计越能提高代码的灵活性越能应对未来的需求变化。好的代码设计不能能应对当下的需求而且在将来需求发生变化的时候仍然能在不破坏原有代码设计的情况下灵活应对。而抽象就是提供代码扩展性、灵活性、可维护性最有效的手段之一。
7.多用组合少用继承
为什么不推荐使用继承
继承是面向对象的四大特性之一用来表示 is-a 关系可以解决代码复用的问题。虽然继承有诸多作用但继承层次过深、过复杂也会影响到代码的可维护性。在这种情况下我们应该尽量少用甚至不用继承。
组合相比继承有哪些优势
继承的主要作用有三个表示 is-a 关系、支持多态特性、代码复用。而这三个作用都可以通过组合、接口、委托三个技术手段来达成。此外利用组合还能解决层次过深、过复杂的继承关系影响代码可维护性的问题。
如何判断该用组合还是继承
尽管我们鼓励多用组合少用继承但组合也并不是完美的继承也并非一无是处。在实际的项目开发中我们还是要根据具体的情况来选择该用继承还是组合。
如果类之间的结构稳定层次比较浅关系不复杂我们就可以大胆地使用继承。反之我们就尽量使用组合来替代继承。还有一些设计模式、特殊的应用常见会固定使用组合或者继承。
8.贫血模型 VS 充血模型
我们平时做 WEB 项目的业务大部分都是基于贫血模型的 MVC 三层架构被称为传统开发模式。之所以称之为 “传统”是相对于新兴的基于充血模型的 DDD 开发模式来说的。基于贫血模型的传统开发模式是典型的面向过程的编程风格。相反基于充血模型的 DDD 开发模式是典型的面向对象的编程风格。
不过DDD 也并非银弹。对于业务不复杂的系统开发来说基于贫血模型的传统开发模式简单够用基于充血模型的 DDD 开发模式有点大材小用无法发挥作用。相反对于业务负责的系统开发来说基于充血模型的 DDD 开发模式因为前期需要在设计上投入更多的时间和经历来提高代码的复用性和可维护性所以相比于基于贫血模型的开发模式更加有优势。
基于充血模型的 DDD 开发模式跟基于贫血模型的传统开发模式相比主要区别在 Service 层。在基于充血模型的开发模式下我们将部分原来在 Service 类中的业务逻辑移动到了一个充血的 domain 领域模型中让 Service 类的实现依赖这个 domain 类。不过Service 类并不会完全移除而是复杂一些不适合放在 domain 领域模型类中的功能。比如负责与 Repository 层打交道、跨领域模型的业务聚合功能、幂等事务等非功能性的工作。
基于充血模型的 DDD 开发模式跟基于贫血模型的传统开发模式相比Controller 层和 Repository 层的代码基本上相同。这是因为Repository 层的 Entity 生命周期有限Controller 层的 VO 只是单纯作为一种 DTO。两部分的业务逻辑都不会太复杂。业务逻辑主要集中在 Service 层。所以Controller 层和 Repository 层继续沿用贫血模型的设计思路是没有问题的。
设计原则
1.SOLID 原则SRP 单一职责原则
一个类只负责完成一个职责或者功能。单一职责原则通过避免设计大而全的类避免将不相关的功能耦合在一起来提高类的内聚性。同时类职责单一类依赖的和被依赖的其他类也会变少减少了代码的耦合性以此来实现代码的高内聚、松耦合。但是如果拆分得过细实际上会适得其反反倒会降低内聚性也会影响代码的可维护性。
不同的应用常见、不同阶段的需求背景、不同的业务层面对同一个类的职责是否单一可能会有不同的判定结果。实际上一些侧面的判断指标更具有指导意义和可执行性比如出现下面这些情况就有可能说明类的设计不满足单一职责原则
类中的代码行数、函数或者属性过多类依赖的其他类过多或者依赖类的其他类过多私有方法过多比较难给类起一个合适的名字类中大量的方法都是集中操作类中的几个属性。
2.SOLID 原则OCP 开闭原则
如何理解 “对扩展开发、对修改关闭”
添加一个新的功能应该是通过在已有代码基础上扩展代码新增模块、类、方法、属性等而非修改代码已有代码修改模块、类、方法、属性等的方式来完成。关于定义我们有两点要注意。
第一点是开闭原则并不是说完全杜绝修改而是以最小的修改代码的代价来完成新功能的开发。第二点是同样代码的改动在粗代码粒度下可能被认为是 “修改”在细代码粒度下可能有被认为 “扩展”
如何做到 “对扩展开发、对修改关闭”
我们要时刻具备扩展意识、抽象意识、封装意识。在写代码时我们要多花点时间思考下这段代码未来可能有哪些需求变更如何设计代码结构事先留好扩展点以便在未来需求变更时在不改动代码整体结构、做到最小代码改动的情况下将新的代码灵活地插入到扩展点上。
很多设计原则、设计思想、设计模式都是以提高代码的扩展性为最终目的。特别是 23 种经典设计模式大部分都是为了解决代码的扩展性问题而总结出来的都是以开闭原则为指导原则的。最常用来提高代码可扩展性的方法有多态、依赖注入、基于接口而非实现编程以及大部分的设计模式比如装饰、策略、模板、职责链、状态。
3.SOLID 原则LSP 里氏替换原则
子类对象Object of subtype/derived class能够替换程序中父类对象出现的任何地方并且保证原来程序的逻辑行为不变及正确性不被破坏。
里氏替换原则是用来指导继承关系中子类该如何设计的一个原则。理解里氏替换原则最核心的就是理解 “design by contract按照协议来设计” 这几个字。父类定义了函数的 “约定”子类可以改变函数的内部实现逻辑但不能改变函数的原有 “约定” 包括函数声明要实现的功能对输入、输出、异常的约定甚至包括注释中所罗列的任何特殊说明。
理解这个原则我们还要弄明白里氏替换原则跟多态的区别。虽然从定义描述和代码实现上来看多态和里氏替换原则有点类似但它们关注的角度是不一样的。多态是面向对象编程的一大特性也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里氏替换原则是一种设计原则用来指导继承关系中子类该如何设计子类的设计要保证在替换父类的时候不改变原有程序的逻辑及不破坏原有程序的正确性。
4.SOLID 原则ISP 接口隔离原则
接口隔离原则的描述是客户端不应该强迫依赖它不需要的接口。其中的 “客户端”可以理解为接口的调用者。理解 “接口隔离原则” 的重点是理解其中的 “接口” 二字。这里有三种不同的理解。
如果把 “接口” 理解为一组集合可以是某个微服务的接口也可以是某个类库的接口等。如果部分接口只被部分调用者使用我们就需要将这部分接口隔离出来单独给这部分调用者使用而不强迫其他调用者也依赖这部分不会被用到的接口。
如果把 “接口” 理解为单个 API 接口或函数部分调用者只需要函数中的部分功能那我们就需要把函数拆分成粒度更细的多个函数让调用者只依赖它需要的那个细粒度函数。
如果把 “接口” 理解为 OOP 中的接口也可以理解为面向对象编程语言中的接口语法。那接口的设计要尽量单一不要让接口的实现类和调用者依赖不需要的接口函数。
5.SOLID 原则DIP 依赖倒置原则
**控制反转**实际上控制反转是一个比较笼统的设计思想并不是一种具体的实现方法一般用来指导框架层面的设计。这里所说的 “控制” 指的是对执行流程的控制而 “反转” 指的是在没有使用框架之前程序员自己控制整个程序的执行。在使用框架之后整个程序的执行流程通过框架来控制。流程的控制权从程序员 “反转” 给了框架。
**依赖注入**依赖注入和控制反转恰恰相反它是一种具体的编程技巧。我们不通过 new 的方式在类内部创建依赖的对象而是将依赖类对象在外部创建好之后通过构造函数、函数参数等方式传递或 “注入”给类来使用。
**依赖注入框架**通过依赖注入框架提供的扩展点简单配置一下所需要的类及其类之间的依赖关系就可以实现由框架来自动创建对象、管理对象生命周期、依赖注入等原本需要程序员来做的事情。。
**依赖反转原则**也叫做依赖倒置原则。这条原则跟控制反转有点类似主要用来指导框架层面的设计。高层模块不依赖低层每块它们依赖一个共同抽象。抽象不需要依赖具体实现细节具体实现细节依赖抽象。
6.KISS、YAGNI 原则
KISS 原则的中文描述是尽量保持简单。KISS 原则是保持代码可读性和可维护性的重要手段。KISS 原则中的 “简单” 并不是以代码行数来考量的。代码行数越少并不是代表代码越简单我们还要考虑逻辑复杂度、实现难度、代码的可读性等。而且本身就复杂的问题用复杂的方法解决也并不违背 KISS 原则。此外同样的代码在某个业务场景下不满足 KISS 原则换一个应用场景可能就不满足了。
对于如何写出满足 KISS 原则的代码总结了下面几条指导原则
不要使用同事坑你不懂的技术来实现代码不要重复造轮子善于使用已经有的工具类库不要过度优化
YAGNI 原则的英文全称是You Ain’t Gonna Need It。直译就是你不需要它。这条原则也算是万金油了。当用在软件开发中时它的意思是不要去设计用不到的功能不要是编写当前用不到的代码。实际上这条原则的核心思想是不要过度设计。
YAGNI 原则跟 KISS 原则并非一回事儿。KISS 原则讲的是 “如何做” 的问题尽量保持简单而 YAGNI 原则说的是 “要不要做” 的问题当前不需要的就不要做。
7.DRY原则
DRY 原则中文描述是不要重复自己将它应用在编程中可以理解为不要写重复的代码。
有三种代码重复的情况实现逻辑重复、功能语义重复、代码执行重复。实现逻辑重复但语义功能不重复的代码并不违反 DRY 原则。实现逻辑不重复但功能语义重复的代码也算违反 DRY 原则。而执行代码重复的代码也算违反 DRY 原则。
此外我们还降到了提高代码复用性的一些手段包括减少代码耦合、满足单一职责原则、模块化、业务与非业务逻辑分离、通用代码下沉、继承、多态、封装、抽象、应用模板等设计模式。
复用意识也非常重要。在设计每个模块、类、函数的时候要像设计一个外部 API 一样去思考它的复用性。
我们在第一次写代码的时候如果当下没有复用的需求而未来的复用需求也不是特别明确并且开发可复用代码的成本比较高那我们就不需要考虑代码的复用性。在之后开发新的功能的时候发现可以复用之前写的这段代码那我们就重构这段代码让其变得可复用。
相比于代码的复用DRY 原则适用性更强一些。我们可以不写可复用的代码但一定不能写重复的代码、
8.LOD原则
如何理解 “高内聚、松耦合”
“高内聚、松耦合” 是一个非常重要的设计思想能够有效提高代码的可读性和可维护性缩小功能改动导致的代码改动范围。“高内聚” 用来指导类与类之间依赖关系的设计。所谓高内聚就是指相近的功能应该放到同一个类中不相近的功能不要放到同一个类中。相近的功能往往会被同时修改放到同一个类中修改会比较集中。所谓 “松耦合” 指的是在代码中类与类之间的依赖关系简单清晰。即使两个类有依赖关系一个代码的改动也不会或很少导致依赖类的代码改动。
如何理解 “迪米特法则”
迪米特法则的描述为不该有直接依赖关系的类不要有依赖有依赖关系的类之间尽量只依赖必要的接口。迪米特法则是希望较少类之间的耦合让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化需要了解这一变化的类就会比较少。
规范与重构
1.重构概述
重构的目的为什么重构why
对于项目来说重构可以保持代码质量持续处于一个可控状态不至于腐化到无可救药的地步。对于个人而言重构非常锻炼一个人的代码能力并且是一件非常有成就感的事情。它是我们学习经典设计思想、原则、模式、编程规范等理论知识的练兵场。
重构的对象重构什么what
按照重构的规模可以将重构分为大规模高层次的重构和小规模低层次的重构。
大规模高层次重构包括对代码分层、模块化、解耦、梳理类之间的交互关系、抽象复用组件等等。这部分工作利用的更多的是比较抽象、比较顶层的设计思想、原则、模式。小规模低层次重构包括命名规范、注释、修正函数参数过多、消除超大类、提取重复代码等编程细节主要是针对类、函数级别的重构。小规模低层次重构更多的是利用编码规范这一理论知识。
重构的时机什么时候重构when
一定要建立持续重构的意识把重构作为开发不可少的部分融入到开发中而不是等到代码出现很大问题的时候再大刀阔斧地重构。
重构的方法如何重构how
大规模高层次重构难度比较大需要有组织、有计划地进行分阶段小步快跑时刻保持代码处于一个可运行的状态。
小规模低层次重构因为影响范围小改动耗时短所以只要你愿意并且有时间随时随地都可以去做。
2.单元测试
什么是单元测试
单元测试是代码层面的测试用于测试 “自己” 编写的代码的逻辑正确性。单元测试顾名思义是测试一个 “单元”这个 “单元” 一般是类或函数而不是系统或模块。
为什么要写单元测试
单元测试能有效地发现代码中的 bug、代码设计上的问题。写单元测试的过程本身就是代码重构的过程。单元测试是对集成测试的有力补充能帮助我们快速熟悉代码是 TDD 可落地执行的折中方案。
如何编写单元测试
写单元测试就是针对代码设计覆盖各种输入、异常、边界条件的测试用例并将其翻译成代码的过程。可以利用一些测试框架来简化测试代码的编写。对于单元测试我们需要建立以下正确的认知
编写单元测试尽管繁琐但并不是太耗时可以稍微放低单元测试的质量要求覆盖率作为衡量单元测试好坏的唯一标准是不合理的写单元测试一般不需要了解代码的实现逻辑单元测试框架无法测试多半是代码的可测试性不好。
单元测试为何难落地执行
一方面写单元测试本身比较繁琐技术挑战不大很多程序员不愿意去写。另一方面国内研发比较偏向 “快、糙、猛”容易因为开发进度紧导致单元测试的执行虎头蛇尾最后没有建立单元测试的正确认识觉得可有可无单靠督促很难执行得很好。
3.代码的可测试性
什么是代码的可测试性
粗略的讲所谓的代码的可测试性就是针对代码编写单元测试的难易程度。
对于一段代码如果很难为其编写单元测试或者单元测试写起来很费劲需要依靠单元测试框架很高级的特性那往往就意味着代码设计得不够合理代码的可测试性不好。
编写可测试性代码的最有效手段
依赖注入是编写可测试性代码的最有效手段。通过依赖注入我们在编写单元测试代码的时候可以通过 mock 的方法将不可控的依赖变得可控这也是我们在编写单元测试的过程中最有技术挑战的地方。除了 mock 方式我们还可以利用二次封装来解决某些代码行为不可控的情况。
场景的 Anti-Patterns
典型的、常见的测试不友好的代码有下面这 5 种
代码中包含未决行为逻辑滥用全局变量滥用静态方法使用复杂的继承关系高度耦合的代码。
4.大型重构解耦
“解耦” 为何如此重要
过于复杂的代码往往在可读性、可维护性上都不友好。解耦保证代码松耦合、高内聚是控制代码复杂度的有效手段。如果代码松耦合、高内聚也就意味着代码结构清晰、分层、模块化合理、依赖关系简单、模块或类之间的耦合小那代码整体的质量就不会差。
代码是否需要 “解耦”
间接的衡量标准有很多比如
改动一个模块或类的代码受影响的模块或类是否有很多改动一个模块或类的代码依赖的模块或者类是否需要改动代码的可测试性是否好…
直接的衡量标准是把模块与模块之间及其类与类之间的依赖关系画出来根据依赖关系图的复杂性来判断是否需要解耦重构。
如何给代码 “解耦”
给代码解耦的方法有封装与抽象、中间层、模块化以及一些其他的设计思想与原则比如单一职责原则、基于接口而非实现编程、依赖注入、多用组合少用继承、迪米特法则。当然还有一些设计模式比如观察者模式。
5.小型重构编码规范
前面讲了很多设计原则后面还会讲到设计模式利用好它们都可以有效地改善改代码的质量。但是这些知识的合理应用非常依赖个人经验有时候用不好会适得其反。但是编码规范正好相反大部分都简单明了在代码的细节方面能立竿见影地改善质量。此外前面也讲到持续低层次小规模重构依赖的基本上都是这些编程规范也是改善代码可读性的有效手段。
我总结罗列了 20 条编码规范分为三个大类命名与注释、代码风格、编程技巧。
命名与注释
命名的关键是能准确的达意。对于不同作用域的命名可以适当的选择不同的长度作用域小的命名比如临时变量等可以适当的选择短一些的命名方式。此外命名中也可以使用耳熟能详的缩写。借助类的信息来简化属性、函数的命名利用函数的信息来简化函数参数的命名。命名要可读、可搜索。不要使用生僻的、不好读的英文单词来命名。此外命名要符合项目的统一规范也不要用那些反直觉的命名。接口有两种命名方式。一种是在接口中带前缀 “I”另一种是在接口的实现类中带后缀 “Impl”。两种命名方式都可以关键要在项目中统一。对于抽象类的命名我们更倾向于带有前缀 “Abstract”。注释的目的就是让代码更容易看懂只要符合这个 要求你就可以写。总结以下的话注释主要包含这样三个方面的内容做什么、为什么、怎么做。对于一些复杂的类和接口我们可能还需要写明“如何用”。注释本身有一定的维护成本所以并非越多越好。类和函数一定要写注释而且要写的尽可能全面详细些而函数内部的注释会相对少一些一般都是靠好的命名和提炼函数、解释性变量、总结性注释来做到代码易读。
代码风格
代码风格没有对错之分不同的编程语言风格都不太一样只要能在团队、项目中统一即可不过最好能跟业务推荐的风格、开源项目的代码风格一致。所以这里就不展开罗列了你可以对照这自己属性的编程语言的代码风格自己复习以下。
编程技巧
将复杂的逻辑提炼拆分成函数和类通过拆分多个函数的方式来处理参数过多的情况通过参数封装为对象来处理参数过多的情况函数中不要使用参数来做代码执行逻辑的控制移除过深的嵌套层次方法包括去掉多余的 if 或 else 语句使用 continue、break、return 关键字提前退出嵌套调整执行顺序来减少嵌套将部分嵌套逻辑抽象成函数用字面常量取代魔法值利用解释下变量来解释复杂表达式。
统一编码规范
除了细节的知识点外最后还有一条非常重要的那就是项目、团队甚至公司一定要制定统一的编码规范并且通过 Code Review 督促执行这对提供代码质量有立杆见影的效果。
