编程的首要原则是什么?

半年前,JoelOnSoftware和CodingHorror合搞的stackoverflow.com刚上线不久,我兴冲冲地跑过去扔了一个问题:

你们认为编程的首要原则是什么?(此文还是作者写于2009年的文章,这个问题是在2008年10月提交的)

作为我的学习原则的一个实践:

学习一项知识,必须问自己三个重要问题:1. 它的本质是什么。2. 它的第一原则是什么。3. 它的知识结构是怎样的。

5个月过去了,这个问题到现在还有人回复,我得到了一大堆有意思的答案,忍不住翻译过来与大家分享:

1. 获得最多认同的答案:

KISS – Keep It Simple Stupid

DRY – Don’t Repeat Yourself

一点不感到意外吧?

注:DRY原则倒是比较好理解和实践的。但KISS原则则是看上去直白,其实实践起来不那么容易的一个原则,因为simple和stupid的定义并不是每个人、在每个场景下都是一致且明显的,一个人的simple可能是另一个人的stupid,一个人的stupid可能是另一个人的unnecessary。一旦一个标准取决于具体场景,事情就不那么简单了。所以我们经常要说“It depends”。

2. 获得第二认同的答案:

写代码时时刻设想你就是将来要来维护这坨代码的人。

在这个答案后面有人添加到:

最好设想你的代码会被一个挥着斧头的精神病来维护。

有人接着又YY道:

而且这个挥着斧头的精神病还知道你住在哪儿。1

注:其实这个原则在设计API时也有用:

写API时时刻设想你就是要去使用这坨API的人。

 

伯乐在线编注:在编写代码的时候,你要经常想着,那个最终维护你代码的人可能将是一个有暴力倾向的疯子,并且他还知道你住在哪里。—— 里克·奥斯本 )

3. 一些众所不一定周知的答案

先弄清你的问题是什么!

弄清问题永远是问题解决过程中的第一步和最重要的一步。

代码只是工具,不是手段。

不知道怎么最好地解决你手头的问题(注:需求、架构、算法,技术选型,etc..),写上一万坨代码也是浪费比特。

知道什么时候不该编码

(类似条目:YAGNI——“你并不需要编写这坨代码!”,针对你的需求编码,“写你所需”,别做“聪明事”,为一个不确定的未来编码。同时也注意模块化设计,以便能在未来新增需求时无痛扩充系统)

永远不要假定你已经了解一切了!

不作没有证据的推论。

想清楚了再编写。类似条目:如果方案在你脑子里面或者纸上不能工作,写成代码还是不能工作。

4. 一些众所很可能周知的答案:

越懒越好。

过早优化是一切罪恶的根源。

不要重新发明轮子。

测试通过前说什么“它可以工作”都是纯扯淡。

了解你的工具。

一切以用户需求为导向。

利用分治、抽象,解开子问题之间的耦合。

5. 最幽默的答案

咖啡进,代码出。(Coffee in, Code out)2

(伯乐在线编注:也有这样一句俗语: Programmer – an organism that turns coffee into software. – Author Unknown 程序猿:一种把咖啡转变成软件的生物。—— 无名氏)

最后,整个问题的 thread 在这里

Footnotes:

  1. 事实上后面有人指出这是 Martin Golding 的一句名言 [?]
  2. 参见 Garbage in, Garbage out. [?]
take a rest with coffee
1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部