《高效能程序员的修炼》一第3章 高效编程之原则

        初次邂逅......        最近小编抽空看了一本书,书的名字叫做<高效能程序员的修炼>,从这本书的名字就能看出来,软件开发远不只是写代码那么简单,你要学会的是高效能的工作,这让小编想到了去年读过的一本书<高效能人士的七个习惯>,有兴趣的小伙伴可以看看哦,受益匪浅,<高效能程序员的修炼>这本书从人文角度而非技术角度去阐释了作为一个程序员,应该具备的基本素质,所以小编在看这本书的过程中,感到非常的有共鸣,通俗易懂,又很贴近小逼啊工作和生活中的实际,

向橡皮鸭求助 高效能程序员的修炼 在Stack Exchange上,我们坚持要求提出问题的人需要在自己的问题上多下些功夫,而且我们在这方面有些偏执.那就是说,当你开始要提问题的时候,你应该: 用足够多的细节来描述发生的状况,这样我们可以顺着你的描述继续研究下去.即使在你所在的特定领域里我们并不是专家,你也要向我们提供必要的背景情况,这样我们可以了解到底发生了什么事情. 告诉我们你为什么需要知道答案.你怎么会出现在这里?是闲来无事的好奇,还是在某个项目里遇到了障碍?我们不是要求你长篇大论地讲生活故

如何培养写作习惯 高效能程序员的修炼 我得忏悔一下:程序员同胞们,从某种程度上来说,我创办的Stack Overflow网站"耍"了大家. 在你找来棍棒准备揍我之前,请允许我先解释一下. 在过去的6年时间里,我越来越坚定地有了这样一个想法,那就是:成为一名杰出的程序员其实跟写代码没有太大的关系.做程序员确实需要一些技能,当然,还要有坚韧不拔的精神.但除此之外,更重要的还是要有良好的沟通技巧. 杰出的程序员跟勉强过得去的程序员之间的差别,不在于他们掌握了多少种编程语言,也不在于他们谁更擅

大道至简 高效能程序员的修炼 作者在Twitter上发的一条短讯: "你永远都有简化的空间." 11:29 AM – 2012-5-21 Rich Skrenta在"Code is our enemy"(代码是我们的敌人)一文中是这么说的: 代码不是什么好东西.代码会随着时间的推移慢慢腐烂.代码需要周期性的维护.代码里还藏有bug.新增功能意味着旧的代码需要被修改.你的代码越多,bug能藏身的地方就越多,迁出(checkout)或者编译的时间也就越长,新员工理解你的

一路向前冲 高效能程序员的修炼就运营Stack Overflow这个公司而言,我采用的商业策略全来自一个人,而且只有这一个人:Curtis Armstrong. 更准确地说,是Curtis Armstrong在1985年的经典荒诞青春喜剧<再见人生>(<Better Off Dead>)中所扮演的Charles De Mar.当他被问到如何从一个特别险峻的高山上滑雪下去的时候,他回答道: 沿着那条路下去,一定要快.如果有什么东西挡住了你的去路--绕开它! 在我们宣布Stack Ov

磨刀不误砍柴工 高效能程序员的修炼作为一名软件开发人员,你该如何磨快你的锯子? "磨锯子"实际上是一个代名词,泛指一切编程以外的活动(不必编写代码),而这些活动(从理论上来说)能使你成为一名更出色的程序员.这个词源自于Covey的一本书:<高效能人士的7个习惯>(<The 7 Habits of Highly Effective People>).1 有个人在山间漫步,偶遇一位伐木工.他便停下来观察这位伐木工,看他热火朝天地锯一棵很大的树.他发现这位伐木工干得大

性能致胜 高效能程序员的修炼在Stack Overflow和Stack Exchange上,我们总是非常强调性能.不仅仅因为我们是性能的发烧友(我很内疚),也因为我们认为速度是一个竞争优势.已经有大量的实验数据表明,网站载入和显示的速度越慢,使用它的人就会越少. Google发现,显示10个结果的网页需要0.4秒来生成,显示30个结果的网页需要0.9秒来生成.半秒钟的延迟会造成20%的流量下降.半秒钟的延迟就扼杀了用户的满意度. 在A/B1测试中,亚马逊试着以100毫秒为单位逐步增加页面的延迟,

学会读源代码 高效能程序员的修炼在"沟通"这个复杂的领域里,写出能让人类领会并理解的连贯段落比敲出几行不至于让解释器或编译器"呕吐"的软件代码要难得多. 这就是为什么--就软件开发而言--所有的文档大概都是很差劲的.而且,由于为人写作比为机器写作要困难得多,恐怕在可预见的将来,文档还会继续差劲下去.对此,你基本上是无能为力的. 除了做一件事-- "卢克1,学着去读源代码." JavaScript"始终带有源代码"是一股革命性的

译者序 高效能程序员的修炼出版社的冀康一开始来找我谈翻译这本书的时候,我的第一反应是:这兄弟真是不知道我现在有多忙!我每天要处理200多封邮件:在资源有限的情况下经常要同时带6-7个项目,而且每个项目的交付计划都很紧,压力很大:每天起码工作12个小时,有时候还要熬夜跟美国同事开会:周六基本上也是工作状态--我哪里还有空来翻译书?! 后来,当我了解到这本书的作者是Stack Overflow网站的创始人Jeff Atwood,还有书的内容实际上就是从作者的博客网站Coding Horror精选而来

关于多任务的神话 高效能程序员的修炼在<质量·软件·管理:系统思维(第1卷)>一书中,Gerald Weinberg1提出了一个经验法则,用以计算由于切换项目而引起的浪费. 根据Weinberg的计算,哪怕在你的工作负荷中只是增加一个项目,也会严重地影响你的效率.你会损失20%的时间.当你增加第三个项目的时候,你会有将近一半的时间浪费在任务切换上面. 即便你同一时间只做一个项目,这种问题也可能会发生.轻易被电子邮件.电话以及即时消息打断你正在进行的工作,其影响可能是深远的,就像BBC2的这个研