生活中的很多道理都是亲身经历过才能真正明白的,在编程中也是一样的,时间和经验能教给你的东西在别处学不到。下面这9点,我必须很艰难地去实践学习!
1.最便宜、最快和最可靠不可兼得
戈登·贝尔(Gordon Bell)曾经说过这样的话。在此要我们学到的是,应该尽可能保持系统或软件简单易懂。降低其复杂性,漏洞也会随之减少。
2.Voodoo编程
很多程序员自始至终都有这样的经历:有时你成功修复了漏洞却不理解问题出在哪里。请务必要理解自己写下的代码,并且找出修改奏效的原因。这种心态会比书本教给你的更多。不要觉得不好意思,实在不明白的话就去向别人请教。没准哪一天,你就会发现自己也变成了别人请教的对象。
复制粘贴代码也是如此。有时候,我们都会使用堆栈溢出,这没关系的。但是如果你不理解代码,要么就别用,要么就找人问问清楚。创造或使用自己不理解的代码也被称为Voodoo编程,这是一个潜在的漏洞。
3.代码不会骗人,但有时注释会
注释起着很重要的作用,但是如果可以的话,尽量不要使用注释,而是书写更多的描述性代码。这是因为在你修改代码的时候,注释往往会被忽视。因此我这样说:注释有时会骗人(有错误),因为它周围的代码已经改变,而它自己没有被修改。
有三种方法书写代码:
· 在代码中使用注释。
· 将注释写在单独的文件中。
· 书写自我说明的代码。
我来详细说明一下最后一点。下面是书写更多描述性代码的意义:
· 好好设计代码库,使它方便查找且结构合理。
· 不要尝试保存缩写字母。在对变量、类和函数命名的时候使用全称,比如不用wm用windowManager,不用rf用readFileToString。当你或者其他人间隔数月再看代码试图理解其意思时,这种命名方式会有很大帮助。
· 尽可能多地提取函数并让它们各司其职。根据其功能进行命名,比如,创建一个将文件读入字符串的函数,将其命名为readFileToString(String fileName),不用仔细阅读代码就能明白它的作用。
最理想的情况是,你的代码由一系列这样的函数调用组成,读起来就像人类语言一样。只有在需要的时候,读者才会去深入理解,这些代码本身就有说明的作用。
4.正则表达式
在面对问题时,有些人会想:“要用正则表达式!”好的,现在他要面临两个问题了。这个笑话有点儿年头了,但依然是人间真实。正则表达式是一种痛苦,当你以为终于为一个案例找到正确答案的时候,对于下一个案例就只有70%匹配。
以上仅仅是我的想法,除非万不得已,建议不避免滥用正则表达式。通常,像split、substring、endsWith、indexOf等函数的组合将会产生更加易读的代码。
5.软件就像大教堂:我们建造它们——然后祈祷
《大教堂与集市》一书对比了两种不同的开发模式。正如维基百科中所写:
“在大教堂模式下,每个软件版本都可以获得源代码,但在不同版本之间开发的代码仅限于软件开发人员这个专属群体;集市模式下,代码是在公众视野中通过互联网开发的。Linux内核项目的领导者林纳斯·托瓦兹(Linus Torvalds)被认为是这个过程的发明者。”
两种模式各有利弊。然而,人们普遍认为软件需要迭代开发,在这个过程中其功能逐渐变多,所以终端用户最好从早期就参与开发过程。
6.在便宜、快速和可靠中三选二
我喜欢这个部分,它让听者(你的经理)自己思考:
· 你想要可靠且快速?可以是可以,但你要聘用最好的程序员。
· 又便宜又快?那就别指望它可靠了!
· 又可靠又便宜?也许你很幸运,但是你需要花费更多时间找到廉价的劳动力,或者需要大量迭代(因此需要更多时间)才能做好。
7.在软件工程中有两件难事
· 0.命名
· 1.缓存失效
· 2.大小差一
我们人类一般会从1开始计数,而计算机从0开始。这项简单的事实成为了很多漏洞和困难的来源。你很可能已经犯过大小差1的错误,如果还没,别着急,它们总会找上你。
8.好的程序员在通过单行道时会查看两边
最好的程序员可以处理所有错误,注意,我说的是所有,即使是那些“永远不会出现的错误”。
大多数软件都是为了实现“快乐流”而编写的——一切都按照预期进行,用户不会做些奇怪的事情。然而现实世界是混乱的,随着时间的推移,有潜在风险的事情也会出错。尝试捕捉尽可能多的错误,特别是当你的软件正在实现重要功能的时候。
9.按代码行衡量编程进度就像按重量衡量飞机制造进度一样
更多代码行并不代表更多进度。同样,书写更多代码并不意味着你比别人更高效。最好的代码应该能够言简意赅地完成任务,这也是最难写的。这是一个众所周知的软件原理,叫作KISS,是“Keep It Simple, Stupid(保持简单、易懂)”的缩写。
如果对哪条感到不甚理解,没关系的,你只需要记住它们,然后静候实际经历的那一刻让你深刻理解它。