《程序员名言 2.docVIP

软件在能够复用前必须先能用。 –Ralph Johnson 优秀的判断力来自经验，但经验来自于错误的判断。 –Fred Brooks ‘理论’是你知道是这样，但它却不好用。‘实践’是它很好用，但你不知道是为什么。程序员将理论和实践结合到一起：既不好用，也不知道是为什么。 –佚名 当你想在你的代码中找到一个错误时，这很难；当你认为你的代码是不会有错误时，这就更难了。 -Steve McConnell《代码大全》 如果建筑工人盖房子的方式跟程序员写程序一样，那第一只飞来的啄木鸟就将毁掉人类文明。 -Gerald Weinberg 项目开发的六个阶段： 充满热情 醒悟 痛苦 找出罪魁祸首 惩罚无辜 褒奖闲人 –佚名 优秀的代码是它自己最好的文档。当你考虑要添加一个注释时，问问自己，“如何能改进这段代码，以让它不需要注释？” -Steve McConnell《代码大全》 我们这个世界的一个问题是，蠢人信誓旦旦，智人满腹狐疑。 –Bertrand Russell 无论在排练中演示是如何的顺利(高效)，当面对真正的现场观众时，出现错误的可能性跟在场观看的人数成正比。 –佚名 罗马帝国崩溃的一个主要原因是，没有0，他们没有有效的方法表示他们的C程序成功的终止。 –Robert Firth C程序员永远不会灭亡。他们只是cast成了void。 –佚名 如果debugging是一种消灭bug的过程，那编程就一定是把bug放进去的过程。 –Edsger Dijkstra 你要么要软件质量，要么要指针算法；两者不可兼得。 –(Bertrand Meyer) (有思想的话…) 有两种方法能写出没有错误的程序；但只有第三种好用。 –Alan J. Perlis 用代码行数来测评软件开发进度，就相对于用重量来计算飞机建造进度。 –比尔-盖茨 最初的90%的代码用去了最初90%的开发时间。余下的10%的代码用掉另外90%的开发时间。 –Tom Cargill 程序员和上帝打赌要开发出更大更好——傻瓜都会用的软件。而上帝却总能创造出更大更傻的傻瓜。所以，上帝总能赢。 –Anon “设计是一个发现问题、而不是发现解决方案的过程” —— Leslie Chicoine “过去的代码都是未经测试的代码” —— Michael Feathers “任何傻瓜都能写出计算机可以理解的代码。好的程序员能写出人能读懂的代码” ——Martin Fowler “测试是来表明bug的存在而不是不存在” —— Edsger Dijkstra “简单不先于复杂，而是在复杂之后” —— Alan Perlis 1. 无风不起浪 别紧张，这也许只是一场消防演习 代码设计是否糟糕，从某些地方就可以看出来。比如： ?a. 超大类或超大函数 ?b. 大片被注释的代码 ?c. 逻辑重复 ?d. If/else嵌套过深 程序员们通常称它们作代码异味(Code Smell)，但是就我个人认为“代码警报”这个名字更为合适一些，因为它有更高的紧迫感的含义。根本问题处理不当，终将引火烧身。 译注：Code Smell中文译名一般为“代码异味”，或“代码味道”，它是提示代码中某个地方存在错误的一个暗示，开发人员可以通过这种smell（异味）在代码中追捕到问题。 2. 预防为主，治疗为辅 好吧，我相信了！ 20世纪80年代，丰田公司的流水作业线因为它在缺陷预防方法上的革新变得出了名的高效。每个发现自己的部门有问题的成员都有权暂停生产。这个方法意在宁可发现问题后马上暂定生产、解决问题，也不能由其继续生产而导致更棘手且更高代价的修复/更换/召回后的问题。 程序员总会做出生产率就等同于快速编码的错误臆断。许多程序员都会不假思索地直接着手代码设计。可惜，这种Leeroy Jenkins式鲁莽的做法多会导致软件的开发过程变得很邋遢，拙劣的代码需要不断的监测和修改——也可能会被彻底地替换。最终，生产率所涉及到的因素就 不仅仅是写代码所消耗的时间了，还要有调试的时间。稍不留神就会“捡了芝麻丢了西瓜”。（因小失大。） 译注：Leeroy Jenkins 行为：WOW游戏中一位玩家不顾大家独身一人迎敌，导致灭团。 3. 不要孤注一掷 （过度依赖某人） 一个软件开发团队的公共要素（bus factor）是指那些会影响整个项目进程的核心开发人员的总数。比如某人被车撞了或某人生孩子或某人跳槽了，项目可能就会无序，甚至会搁置。 译注： bus factor 即指公共要素，比喻了开发过程中的一些共同因素。如果挤上 bus 的 factor 越多，bus 就越不稳定，所以要控制好 bus factor ，以免问题发生。 换句话说，如果你的团队突然失去了一个主力成员，你会怎么办？生意依旧进行还是戛然而止？ 很不幸，大多数软件团