我最近迷上了这本书,从别人那里搞一段过来。
http://eric.mentor100.com/2008/01/23/%E3%80%8A%E7%90%86%E8%A7%A3%E4%B8%93%E4%B8%9A%E7%A8%8B%E5%BA%8F%E5%91%98%E3%80%8B%E4%B9%A6%E6%91%98/
最近拜读了(美)杰拉尔·温博格的《理解专业程序员》一书,感受颇深,本书通过行内专家的独特视角,介绍了如何成为优秀程序员,如何提高工作绩效等问题。全书由多篇讨论程序员职业的短文组成,内容精彩绝伦,是一部任何在这个变化急剧的领域工作的人都不可错过的重要作品。现摘录经典内容如下,与君共勉。
p8 : 对计算机编程确实需要智力.事实上,这个工作需要太高的智力,以至于没有人真正做的特别好.
p18 : 如果你觉得目前的工作简直难以接受,你应该要么努力改变它,使它能够让人接受,要么干脆离职. 不要用离职来威胁.
p30 : 在某种意义上,其实没有错误的程序,只有“不同“的程序.要想证实是否程序解决了真正的问题,唯一的办法只有让原本提出问题得人考察这个解决方案.
p33 : 要有合适得人引导,一个程序员小组才能够通过评审技术大大提高学习效率.
p39 : 一个专业程序员必须比业余爱好者更能够随机应变.
p45 : 如果我们加班又加班,却因体质下降而导致工作质量受损,那又有什么意义呢?
p54 : 最巨大,持续最长久的那些变化,往往最初只是试图去保留一些东西,而恰恰是这些东西最终受到了最大的改变.
p57 : 传统上呢,大多数数据处理企业都把程序员考虑成普通职员,他们的生产力都是直接计算,而不是根据他们的产品导致的生产力计算的.
p66 : 技术评审有很多形式,可以因地制宜,适合任何机构使用;但如果缺乏技术评审,你在其他改进生产力技巧上花费的大部分金钱很可能就被浪费了.
p69 : “温博格珍贵编程法则”
2.总会剩下一个bug的,你找到这个剩下的,那就会有另一个.
6.需求,设计,编码能以任何速度完成–只有排错花时间.
7.再长,再乱,再复杂的代码,维护者都能把它弄得更糟糕.
8.人人都谈文档,可从来没有人为它做任何事.
p84 : 无论分析员也好,程序员也好(还包括他们的经理),最大的问题是他们太爱想当然.尤其是,他们总以为他们知道自己面对的问题是什么性质–总以为那是一个“测验“,而不是一个“问题“.
p92 : 如果你想提高工作效率,你就要(听上去有点矛盾)在工作中不那么一心一意的投入.你做的任何事情–任何能够刺激大脑的其他机能的事情–都能够提高你作为程序员或者分析师的工作效率.
p104: 如果你想让人以为你聪明,那就认真听人说话,仔细理解人家的意思.如果你想让人家认为你傻,那就不妨经常用你的高见打断别人的话.
p110: 要花多长时间才能理解一段代码,我对这个问题特别感兴趣.在教学中这是个重要问题,但是对于日益增长的程序维护工作,他还要重要的多.
p123: 人家付你工资,更多的是因为你所知道的东西,而不是因为你干的事情.
p125: 既然代码本身就是所有文档的根基,那么为什么不着手提高代码作为文档的质量呢?
http://eric.mentor100.com/2008/01/23/%E3%80%8A%E7%90%86%E8%A7%A3%E4%B8%93%E4%B8%9A%E7%A8%8B%E5%BA%8F%E5%91%98%E3%80%8B%E4%B9%A6%E6%91%98/
最近拜读了(美)杰拉尔·温博格的《理解专业程序员》一书,感受颇深,本书通过行内专家的独特视角,介绍了如何成为优秀程序员,如何提高工作绩效等问题。全书由多篇讨论程序员职业的短文组成,内容精彩绝伦,是一部任何在这个变化急剧的领域工作的人都不可错过的重要作品。现摘录经典内容如下,与君共勉。
p8 : 对计算机编程确实需要智力.事实上,这个工作需要太高的智力,以至于没有人真正做的特别好.
p18 : 如果你觉得目前的工作简直难以接受,你应该要么努力改变它,使它能够让人接受,要么干脆离职. 不要用离职来威胁.
p30 : 在某种意义上,其实没有错误的程序,只有“不同“的程序.要想证实是否程序解决了真正的问题,唯一的办法只有让原本提出问题得人考察这个解决方案.
p33 : 要有合适得人引导,一个程序员小组才能够通过评审技术大大提高学习效率.
p39 : 一个专业程序员必须比业余爱好者更能够随机应变.
p45 : 如果我们加班又加班,却因体质下降而导致工作质量受损,那又有什么意义呢?
p54 : 最巨大,持续最长久的那些变化,往往最初只是试图去保留一些东西,而恰恰是这些东西最终受到了最大的改变.
p57 : 传统上呢,大多数数据处理企业都把程序员考虑成普通职员,他们的生产力都是直接计算,而不是根据他们的产品导致的生产力计算的.
p66 : 技术评审有很多形式,可以因地制宜,适合任何机构使用;但如果缺乏技术评审,你在其他改进生产力技巧上花费的大部分金钱很可能就被浪费了.
p69 : “温博格珍贵编程法则”
2.总会剩下一个bug的,你找到这个剩下的,那就会有另一个.
6.需求,设计,编码能以任何速度完成–只有排错花时间.
7.再长,再乱,再复杂的代码,维护者都能把它弄得更糟糕.
8.人人都谈文档,可从来没有人为它做任何事.
p84 : 无论分析员也好,程序员也好(还包括他们的经理),最大的问题是他们太爱想当然.尤其是,他们总以为他们知道自己面对的问题是什么性质–总以为那是一个“测验“,而不是一个“问题“.
p92 : 如果你想提高工作效率,你就要(听上去有点矛盾)在工作中不那么一心一意的投入.你做的任何事情–任何能够刺激大脑的其他机能的事情–都能够提高你作为程序员或者分析师的工作效率.
p104: 如果你想让人以为你聪明,那就认真听人说话,仔细理解人家的意思.如果你想让人家认为你傻,那就不妨经常用你的高见打断别人的话.
p110: 要花多长时间才能理解一段代码,我对这个问题特别感兴趣.在教学中这是个重要问题,但是对于日益增长的程序维护工作,他还要重要的多.
p123: 人家付你工资,更多的是因为你所知道的东西,而不是因为你干的事情.
p125: 既然代码本身就是所有文档的根基,那么为什么不着手提高代码作为文档的质量呢?