Osheep

时光不回头,当下最重要。

程序猿应该记住的几条基本规则

简简单单几条原则:

  1. 模块的用户永远也不应该被模块的行为所迷惑
  2. 模块要尽可能小,但又不能太小
  3. 代码应该被重用,而不是被拷贝
  4. 模块之间的依赖性应该尽可能降到最小
  5. 错误应该尽早被检测出来,最好是在编译时刻

重点讲两个。

模块的用户永远也不应该被模块的行为所迷惑

最简单的方式是写下多且准确的注释,不过我相信大部分很难做到“准确”。我习惯引用涛神的话,将该条规则表述为要求“代码能够自解释”。

看起来简单做起来难。对于Java程序猿,有几种必要的方式可以帮助你尽可能的做到这一点:

  • 除了对外公布的API和部分重要模块,要求自己不加注任何注释
  • 使用清晰明确的命名,包括变量、函数、类
  • 被确定命名的类、函数、变量,应仅负责单一、确定的功能
  • 使用的时候再声明/创建,并尽可能进行显示的初始化
  • 严格明确对外保证的边界,将精力放在保证公开接口,而不是私有实现
  • 恰当的使用异常和日志
  • 虽然与原则2相悖,但如果合并模块不会使系统变的难以理解,为了简化系统结构我们仍然选择合并

上述方式并不是充分的,我可能会在以后的开发中继续补充重要的方式,也可能不会。因为你需要掌握的是如何思考,而不是记住这些死知识

上述原则部分参考自Google Java Style Guide,建议二者结合阅读。

错误应该尽早被检测出来,最好是在编译时刻

刷题的时候要时刻牢记:

如果可能,尽早的处理边界条件

对于工程开发,可以改编如下:

如果可能,尽早的发现并处理错误

这里的错误包括异常、逻辑错误等。分为两个方面,发现、处理:

  • 发现:要求我们尽早的发现错误,最好是编译期;如果在运行期,就要在处理正常逻辑之前,尽早的检测出错误。特别的,在开发期间,编写完备的测试用例,尽早发现逻辑错误。
  • 处理:发现错误还不够,我们要处理错误。如果是编译或开发期间发生的错误,修改代码即可;如果是运行期发生的错误,记录日志、提前退出、抛出异常都是值得考虑的选择,选择当前保证和当前场景下最合适的。

该原则要和原则1结合起来(任何原则都要和原则1结合),所以记得让你发现、处理错误的代码也是自解释的。

点赞