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

简简单单几条原则:

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

重点讲两个。

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

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

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

  • 除了对外公布的API和部分重要模块,要求自己不加任何注释
  • 使用清晰明确的命名,包括变量、函数、类
  • 被确定命名的类、函数、变量,其功能应单一、确定
  • 使用的时候再声明/创建,并尽可能进行显示的初始化
  • 严格明确对外保证的边界,将精力放在保证公开接口,而不是私有实现
  • 恰当的使用异常和日志,不要用日志代替所有异常,但或许很多ERROR级别的日志都可以用异常来代替
  • 虽然与原则2相悖,但如果合并模块不会使系统变的难以理解,为了简化系统结构我们建议合并部分模块
  • 除非对外发布后不可更改(比如java.util.Set接口),否则,在能保持良好系统结构的前提下,不要面向未来开发(这一点可能很难接受,不过想想什么时候才应该应用设计模式呢?什么时候时候才应该优化性能呢?有需要的时候。如果现在不需要,就不要面向未来开发。)

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

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

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

刷题的时候要时刻牢记:

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

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

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

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

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

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

扫描微信关注我
微信公众号二维码
本文链接:程序猿应该记住的几条基本规则
作者:猴子007
出处:https://monkeysayhi.github.io
本文基于 知识共享署名-相同方式共享 4.0 国际许可协议发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名及链接。
我是猴子007,<br>一只非常特殊的动物,<br>可以从事程序的开发、维护,<br>经常因寻找香蕉或母猿而无心工作。