InfoQ|细节中有上帝,论精简代码( 二 )



现在 , 我们来谈一谈为什么整洁代码如此重要的原因所在:

  • 代码更具可维护性 。
  • 建立可持续发展的业务
  • 它使你看起来更专业 。
  • 易于阅读和理解 。
  • 提高生产率 。
  • 避免重新设计的恶性循环 。
“上帝在细节中” , 建筑师:路德维希·密斯·凡德罗
如前所述 , 精益是一种方法论 , 是一组旨在组织人类活动以在消除浪费的同时提供更多价值的规范 。 但是 , 你无法整理和约束看不见的东西 , 而要真正能"看到"代码 , 代码就必须是可读的 。 你无法改进看不见(无法阅读)的内容 。 所以我们先来讨论整洁(精益)代码原则的第一个支柱 。
可读性
InfoQ|细节中有上帝,论精简代码
本文插图

下面可读性的完美定义:
  • 清晰 。 “如果想快速执行 , 如果想快速完成 , 如果想让代码易于编写 , 请让代码易于阅读”——Robert C.Martin
  • 简单 。 不要过度设计 。
  • 表达的密度 。 使用最少的资源和交互以获得最多结果的艺术 。
有意义的名称:
  • 可以揭示意图的名称(为什么存在 , 其用途以及使用方式) 。
  • 使用动词表示函数名称 , 使用名词表示类和属性 。
  • 变量应表达自身的创建目的 。 (避免使用 var x , 而应使用 var customersIndex)
命名约定:
?一定要选择易于理解的标识符名称 。
?一定要先考虑可读性再考虑简洁 。
?一定要使用语义上有意义的名称 , 而不要使用特定于编程语言的关键字来写类型名称 。 例如 , GetLength 就比 GetInt 更好 。
X 请不要将缩写用作标识符名称的一部分 。 比如应该使用 GetWindow 而不是 GetWin 。
X 请不要使用与广泛使用的编程语言的关键字冲突的标识符 。
X 请不要使用任何不被广泛接受的首字母缩写词 , 就算它们被广泛接纳 , 也只在必要时才使用它们 。
小方法:
  • 一个方法应该是一个只做一件事情的可测试单元 。
  • 保持在 10 到 15 行代码之内 。
  • 如果你的方法更大 , 那么它可能正在做很多不该它来负责的事情 。
  • “尽早返回” 。
接下来 , 我们继续讨论整洁(精益)代码原则的第二大支柱 。
组织由于我们在谈论的是代码 , 因此我们将专注于开发人员的工作 , 而开发人员会经常使用类 。 架构师的工作位于更高的层次上 , 不涉及代码 , 而是处理项目或服务(也称为域 , 微服务等)等等 。 因此我们将专注谈类 。
InfoQ|细节中有上帝,论精简代码
本文插图

InfoQ|细节中有上帝,论精简代码
本文插图

源文件就像报纸的标题 , 其名称应该简单明了 , 光看名称就知道是什么模块 。 源文件的顶部应该提供关于高级概念和算法的信息 , 往下走逐渐展开细节 , 最后则是底层函数和细节 。
3C 原则:
InfoQ|细节中有上帝,论精简代码
本文插图

耦合:软件模块之间的关联性 。
InfoQ|细节中有上帝,论精简代码
本文插图

内聚:模块内部元素结合在一起的紧密程度 。
InfoQ|细节中有上帝,论精简代码
本文插图

InfoQ|细节中有上帝,论精简代码


推荐阅读