程序员编程十条戒律

1.- DRY: Don't repeat yourself.
DRY 是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

DRY 这一法则可能是编程届中最通用的法则了,目前为止,应该没有哪个程序员对这一法则存有异议。但是,我们却能发现,一些程序在编写单元测试(unit testing)时忘记了这一法则:让我们相像一下,当你改变一个类的若干接口,如果你没有使用DRY,那么,那些通过调用一系例类的接口的unit test的程序,都需要被手动的更改。比如:如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法,而是每个test case自己去构造类的实例,那么,当类的构造函数被改变时,你需要修改多少个test cases啊。这就是不使用DRY法则所带来的恶果。

2.- 短小的方法.
至少,我们有下面三个不错的理由要求程序员们写下短小的方法。

代码会变得更容易阅读。
代码会变得更容易重用(短方法可以减少代码间的耦合程度)
代码会变得更容易测试。
3.- 良好的命名规范
使用不错的统一的命名规范可以让你的程序变得更容易阅读和维护,当一个类,一个函数,一个变量的名字达到了那种可以“望文生义”的境界话,我们就可以少一些文档,少一些沟通。文章《编程中的命名设计那点事 》可以给你一些提示。

4.- 赋予每个类正确的职责
一个类,一个职责,这类规则可以参考一下类的SOLID 法则。但我们这里强调的不是一种单一的职责,而是一个正确的职责。如果你有一个类叫Customer,我们就不应该让这个类有sales 的方法,我们只能让这个类有和Customer有最直接关系的方法。

5.- 把代码组织起来
把代码组织起来有两具层次。

物理层组织:无论你使用什么样的目录,包(package)或名字空间(namespace)等的结构,你需要把你的类用一种标准的方法组织起来,这样可以方便查找。这是一种物理性质的代码组织。
逻辑层组织: 所谓逻辑层,主要是说,我们如果把两个不同功能的类或方法通过某种规范联系和组织起来。这里主要关注的是程序模块间的接口。这就是我们经常见到的程序模块的架构。
6.- 创建大量的单元测试
单元测试是最接近BUG的地方,也是修改BUG成本最低的地方,同样也是决定整个软件质量好坏的成败的地方。所以,只要有可能,你就应该写更多的,更好的单元测试案例,这样当你未来有相应代码改变的时候,你可以很简单知道你代码的改变是否影响了其它单元。

7.- 经常重构你的代码
软件开发是一种持续的发现的过程,从而让你的代码可以跟上最新的实际需求的变化。所以,我们要经常重构自己的代码来跟上这样的变化。当然,重构是有风险的,并不是所有的重构都是成功的,也不是我们随时都可以重构代码。下面是两个重构代码的先要条件,以避免让你引入更多的BUG,或是把本来就烂的代码变得更烂。

有大量的单元测试来测试。正如前面所说,重构需要用大量的单元测试来做保障和测试。
每次重构都不要大,用点点滴滴的小的重构来代替那种大型的重构。有太多的时候,当我们一开始计划重构2000行代码,而在3个小时后,我们就放弃这个计划并把代码恢复到原始的版本。所以,我们推荐的是,重构最好是从点点滴滴积累起来的。
8.- 程序注释是邪恶的
这一条一定是充满争议的,大多数程序员都认为程序注释是非常好的,是的,没错,程序注释在理论上是非常不错的。但是,在实际过程序当中,程序员们写出来的注释却是很糟糕的(程序员的表达能力很有问题),从而导致了程序注释成为了一切邪恶的化身,也导致了我们在阅读程序的时,大多数时候,我们都不读注释而直接读代码。所以,在这里,我们并不是鼓励不写注释,而是——如果你的注释写得不够好的话,那么,你还不如把更重要的时间花在重构一下你的代码,让你的代码更加易读,更加清楚,这比会比注释更好。

9.- 注重接口,而不是实现
这是一个最经典的规则了。接口注重的是——“What”是抽象,实现注重的是——“How”是细节。接口相当于一种合同契约,而实际的细节相当于对这种合同契约的一种运作和实现。运作是可以很灵活的,而合同契约则需要是相对需要稳定和不变的。如果,一个接口没有设计好而需要经常性的变化的话,那我们可以试想一下,这代来的后果,这绝对会是一件成本很大的事情。所以,在软件开发和调设中,接口是重中之重,而不是实现。然而我们的程序员总是注重于实现细节,所以他们局部的代码写的非常不错,但软件整体却设计得相对较差。这点需要我们多多注意。

10.- 代码审查机制
所有人都会出错,一个人出错的概率是很大的,两个人出错的概率就会小一些,人多一些,出错的概率就会越来越小。因为,人多了,就能够从不同的角度看待一个事情,虽然这样可能导致无效率的争论,但比起软件产品release后出现问题的维护成本,这点成本算是相当值得的。所以,这就是我们需要让不同的人来 reivew代码,代码审查机制不但是一种发现问题的最有效的机制,同时也是一种可以知识共享的机制。当然,对于Code Review来说,下面有几个基本原则:

审查者的能力一定要大于或等于代码作者的能力,不然,代码审查就成了一种对新手的training。
而且,为了让审查者真正负责起来,而不是在敷衍审查工作,我们需要让审查者对审查过的代码负主要责任,而不是代码的作者。
另外,好的代码审查应该不是当代码完成的时候,而是在代码编写的过程中,不断地迭代代码审查。好的实践的,无论代码是否完成,代码审核需要几天一次地不断地进行。

(0)

相关推荐

  • 程序员编程十条戒律

    1.- DRY: Don't repeat yourself. DRY 是一个最简单的法则,也是最容易被理解的.但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事).它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法. DRY 这一法则可能是编程届中最通用的法则了,目前为止,应该没有哪个程序员对这一法则存有异议.但是,我们却能发

  • Idea公司真牛逼发行最适合程序员编程字体

    正文如下: JetBrains年初的时候推出了一种新字体,即JetBrains Mono,它是专为开发人员设计的. 推荐阅读: https://mp.weixin.qq.com/s/iF1d_I6cij9L-MeQ2QMewg JetBrains表示: 在当今的大部分时间里,我们作为开发人员都在看代码.我们一直在寻找最佳字体,以使我们更容易在屏幕上查看文本. 但是,许多流行字体中的逻辑并不总是考虑到通读代码和阅读书本之间的区别. 我们的眼睛以非常不同的方式沿代码移动,通常必须垂直移动和水平移动,

  • 程序员编程从初级到中级的10个秘诀

    这个观点很好,有关程序员如何从初级跃升到中级的信息极少.以下是为了实现这种转变需要你去做的10件事. 1.学习另一门语言 其实你学的是哪一门语言并没有关系,但是学习另一门语言(不管你已经了解多少种语言)将把你打造为更好的程序员.能学会一门与你日常使用的语言风格迥异的语言则更佳.打个比方,如果你是C#程序员,学习VB.NET或者Java对你的帮助就没有学习Ruby或者Groovy大. 我说"学另一门语言"的意思是要真正学会它.学习一门语言包括三个领域的知识:语法.内置操作符和库,以及&q

  • 程序员编程知识经验总结

    不知道你有没有听说过所谓编程知识也是有半衰期的?这个半衰期限很多人普遍认为是5年.也就是说,5年以后你现在所学的知识将会有一半被淘汰. 感觉听上去也算合情合理.毕竟,新的编程语言和技术在源源不断地面世.但是我要告诉你,编程语言比很多人想得都要"长寿". 语法不是难点 对于Java程序员,学习Python就像说英语的去学习法语.当然这两者是毫无关联的.但是相同的是,都需要学习新的语法.语法只是表面上的不同,所有的核心概念都是相通的. 无论你换哪种编程语言去写程序,我们都可以借鉴其相似的类

  • 新手程序员编程必不可少的工具

    对于程序员来说,编程是一个相当耗费时间和经历的过程,而在这个过程中,一个称手而高效的工具就显得非常重要. 加上近期有不少小伙伴在问一些方方面面的工具,所以今天就总结了一些新手编程能用上的工具一一介绍给小伙伴们,希望对大家的学习和工作有所帮助. 1.Notepad++ 老规矩,每次工具第一推荐,Notepad++是一套非常有特色的自由软件的纯文字编辑器.有完整的中文化接口及支持多国语言编写的功能(UTF8 技术).它的功能比 Windows 中的 Notepad(记事本)强大,十分适合当作编写电脑

  • PHP程序员编程注意事项

    1.不转意html entities   一个基本的常识:所有不可信任的输入(特别是用户从form中提交的数据) ,输出之前都要转意. echo $_GET['usename'] ; 这个例子有可能输出: <script>/*更改admin密码的脚本或设置cookie的脚本*/</script> 这是一个明显的安全隐患,除非你保证你的用户都正确的输入. 如何修复 : 我们需要将"< ",">","and" 等转

  • Java程序员编程性能优化必备的34个小技巧(总结)

    1.尽量在合适的场合使用单例 使用单例可以减轻加载的负担,缩短加载的时间,提高加载的效率,但并不是所有地方都适用于单例,简单来说,单例主要适用于以下三个方面: 控制资源的使用,通过线程同步来控制资源的并发访问: 控制实例的产生,以达到节约资源的目的: 控制数据共享,在不建立直接关联的条件下,让多个不相关的进程或线程之间实现通信. 2.尽量避免随意使用静态变量 要知道,当某个对象被定义为static变量所引用,那么GC通常是不会回收这个对象所占有的内存,如: 此时静态变量b的生命周期与A类同步,如

  • Java 程序员容易犯的10个SQL错误

    Java程序员编程时需要混合面向对象思维和一般命令式编程的方法,能否完美的将两者结合起来完全得依靠编程人员的水准: 技能(任何人都能容易学会命令式编程) 模式(有些人用"模式-模式",举个例子,模式可以应用到任何地方,而且都可以归为某一类模式) 心境(首先,要写个好的面向对象程序是比命令式程序难的多,你得花费一些功夫) 但当Java程序员写SQL语句时,一切都不一样了.SQL是说明性语言而非面向对象或是命令式编程语言.在SQL中要写个查询语句是很简单的.但在Java里类似的语句却不容易

  • C#程序员最易犯的编程错误

    本文介绍了10种最常见的编程错误,或是C#程序员要避免的陷阱. 常见错误1: 像使用值一样使用参考或过来用 C++以及许多其他语言的程序员习惯于控制他们分配给变量的值是否为简易的值或现有对象的引用.在C#中呢,这将由写该对象的程序员决定,而不是由实例化该对象并对它进行变量赋值的程序员决定.这是新手C#程序员们的共同"问题". 如果你不知道你正在使用的对象是否是值类型或引用类型,你可能会遇到一些惊喜.例如: Point point1 = new Point(20, 30); Point

  • 一个30多年编程经验的程序员总结

    在我30多年的程序员生涯里,我学到了不少有用的东西.下面是我这些年积累的经验精华.我常常想,如果以前能有人在这些经验上指点一二,我相信我现在会站得更高. 1.客户在接触到产品之后,才会真正明白自己的需求. 这是我在我的第一份工作上面学来的.只有当我们给客户展示产品的时候,他们才会意识到哪些是必须的.给出一个功能性原型设计远远比一张长长的文字表格要好. 2.只要有充足的时间,所有安全防御系统都将失败. 安全防御现如今是全世界都在关注的大课题.大挑战.我们必须时时刻刻积极完善它,因为黑客只要有一次成

随机推荐