经验分享:干净整洁代码(clean code)的特点 - oliver

20-11-15 banq

干净的代码很重要,干净的代码可以帮助其他人理解您的代码,但是干净的代码也很主观!我想分享给您我的看法,它是由多年的开发人员领导技术团队领导经验和团队合作而成。

干净的代码可以帮助人们理解代码。根据大多数开发人员的意见,您的代码结构越多(不是一地鸡毛一盘散沙),其他开发人员就越可能理解您的代码!

干净代码的一些原则是:

  • 使用有意义且易于理解的标识符
  • 使用函数并使其尽可能短
  • 如果您的代码易于阅读,大部分时间您不需要注释
  • 不要重复自己(DRY)
  • 保持简单,愚蠢!(KISS)
  • 过早的优化是万恶之源
  • 告诉一声即可,不要索要(TDA:Tell, dont ask )
  • Demeter定理
  • 关注点分离
  • 单一责任原则(SRP)
  • 开放封闭原则(OCP)
  • Liskov替代原则(LSP)
  • 接口隔离原则(ISP)
  • 依赖倒置原则(DIP)

简洁的代码可帮助他人理解您的代码,每个开发人员都有自己的编码风格。他们喜欢某些东西,而他们不喜欢。他们喜欢以某种方式做事,因为这对他们最有效。

通过利用众所周知的原则并将其整合到我们自己的工作中,我们为其他意识到这些原则的人打开了可能性,使他们更容易地进入我们的代码库。

就像使用标准化技术一样!以Dockerfile为例。如今,语法大多已标准化。如果您可以编写一个可与​​Docker一起使用的Dockerfile,则还可以使用podman创建一个容器,因为大多数命令都是标准化的!

现在将其转移到我们编写代码的方式。您肯定可以想象,当许多开发人员利用相同的原理来编写和构建其代码时,理解会变得更加容易!

干净的代码是主观的,如上所示,干净的代码利用了许多原理。但是原则就是它们的名字。在某些情况下,几乎不可能给所有人一个严格的方法来做事情。这导致对干净代码的许多解释。

以可读的标识符为例。函数getDogs(ctx){[...]}与函数getDogs(context){[...]}对比,您能确定哪个更易读吗?如果您问5个开发人员,您会收到10个不同的答案。这是主观部分的一个例子。

对于某些开发人员而言,缩写ctx是众所周知的,对于其他开发人员而言则并非如此,他们更喜欢标识符上下文。方法的长度,接口太多或不足是同样的。

与同事讨论干净的代码,并将每条原则转化为团队的特定规则集。以团队的方式共同决定代码的外观。再次讨论是否有人改变主意。

建立一套所有团队成员都可以同意的规则和最佳实践。这样,接受度就会大大提高,人们将更愿意遵循给定的规则。尽可能利用自动化,如linter等!

只要根据您的团队的决定来配置工具,就无需进行人工工作或进行冗长的讨论。如果工具说您做错了,则必须进行调整。如果您认为该规则很糟糕,请作为一个团队进行讨论!

 

对于干净代码,许多初学者和/或新手程序员往往不知所措,这是可以理解的。他们不仅必须学习编写代码,而且每个人都要求他们正确地编写代码。

首先,最好将重点放在基础知识上,然后在基础坚实的情况下尝试使用简洁干净的代码。

 

                   

1
猜你喜欢