跳到主要内容

2.2-代码编写

Create by fall on 03 Feb 2022
Recently revised in 25 Sep 2025

你觉得代码好看还是难看，那只是因为你熟悉或陌生。

好的代码​

这是代码常见问题的一些思考

  • 使用默认导出还是命名导出？
    • 默认导出可以在使用的时候重命名
    • 命名导出，在命名更改的时候，其它地方可以同步更改（不然报错）
  • 文件命名
    • 使用 index.tsx，可以保证你打开一个文件夹知道要找的文件是谁，报错的时候，搜索的时候，就会有成百上千个 index 文件
    • 使用文件夹的名称，可以让搜索更容易，重构时给文件夹重命名也很重要
  • Prop 命名
    • 使用 Props 简单，但如果想要导出这个类型，就还需要再重命名，也很难保持一致，搜索也会有多个结果
    • 使用文件夹的名称，可以让搜索更容易，重构时给文件夹重命名也很重要
  • 普通函数还是箭头函数
    • 普通函数（ES6 之前唯一支持的函数声明方式
    • 箭头函数简洁，紧凑，可读性（一部分人来说）
  • 三步运算符还是提前返回
    • 在返回时使用三步运算符，条件不多，且返回内容简单时非常好，条件多后可读性非常差
    • if 提前返回，多行的内容十分友好，注意使用提前返回可以避免多级嵌套（也不建议 if 中的内容过多，影响理解

如何更好的编写一个应用​

  • Don’t Repeat Yourself，不要重复

  • Keep It Simple, Stupid，让方法保持简单，甚至简单到小白都能懂

  • Program to an interface, not an implementation，面向接口编程，而不是实现

  • You Ain’t Gonna Need It，别因为下次需要在这次编程中实现

  • Law of Demeter，在模块的最顶层询问内容，而不是其中的一部分

  • Common Closure Principle，修改一个功能时，限制在最小的包中

  • Common Reuse Principle，共同重用原则，如果你重用了其中的一个类，就重用全部。

  • Hollywood Principle，组件处在一个容器当中，由容器负责管理

  • High Cohesion & Low/Loose coupling，高内聚， 低耦合

  • Convention over Configuration，惯例优于配置，如果没有自己的规则，使用惯例即可

  • Separation of Concerns，关注点分离，将问题拆解成更小的多个问题，以便于解决

  • Acyclic Dependencies Principle，无环形依赖​

S.O.L.I.D 原则

  • Single Responsibility Principle 单一职责原则一个类，只做一件事，并做好
  • Open / Closed Principle 开闭原则开发封闭原则核心：模块式可扩展，但不可修改的，对扩展开放，对修改封闭
  • Liskov substitution principle 子类应该可以替换任何基类能够出现的地方（子类只扩展基类，不修改基类
  • Interface Segregation Principle 接口隔离原则，把功能实现在接口中，可插拔，而不是由中心控制全部实现
  • Dependency Inversion Principle 依赖倒置原则，高层模块不应该依赖于低层模块的实现，而是依赖于高层抽象。

软件设计原则​

  • 不要重复
  • 让方法保持简单，甚至简单到小白都能懂
  • 面向接口编程，而不是实现
  • 别因为下次需要在这次编程中实现
  • 顶层询问原则，在模块的最顶层询问内容，而不是其中的一部分

组件开发推荐使用强类型语言，因为需要调用对应的 API 实现功能，强类型独有语法提示，类型提示。

只有当同一份代码使用过多次之后，再提取到工具中，视图上同理

命名规则​

尽可能使用方法命名代替注释

/**
 * 求和函数
 * @param {number} a 加数
 * @param {number} b 加数
 * @return {number} sum 和
 */
function getAB(a,b){
  return parseInt(a)+parseInt(b)
}

// 尽可能不使用注释
function sumString(a,b){
  return parseInt(a)+parseInt(b)
}

MNC​

最小必要复杂度原则（Minimum Necessary Complexity, MNC）核心思想是：用最简单的方式满足需求，不增加额外复杂度。

高尔法则​

Gall's Law（高尔法则）：复杂系统必须从简单系统演化，否则无法正常运行。

奥卡姆剃刀：如无必要，勿增实体。

KISS​

KISS 原则：Keep It Simple, Stupid! 让系统保持最小复杂度，减少维护成本。

UNIX 哲学：只做一件事，并做到极致。

1：不要重复2：让方法保持简单，甚至简单到小白都能懂3：面向接口编程，而不是实现4：别因为下次需要在这次编程中实现5，顶层询问原则，在模块的最顶层询问内容，而不是其中的一部分

组件开发​

插件化的架构设计，以 core 为最小应用单元，通过插件的形式向组件内添加多个功能。

好处之一就是可以支持按需加载，此外把独立功能都拆分成独立的插件，会让核心系统更加稳定，拥有一定的健壮性。

使用统一组件，可以保证内容一致

  • 弹窗组件，保证一致的弹窗样式
  • 提示组件，一致的提示样式
  • 错误提示，一致的错误提示