高效程序员的45个习惯 8.2分
读书笔记 全书
雨果僧
### 推荐序

- 没有动机,没有欲望,哪里来的毅力呢?

- 只有明白了“为什么做”,才能够解决“如何做”的问题。

- 内家武功招数:

```

迭代开发,价值优先

分解任务,真实进度

站立会议,交流畅通

用户参与,调整方向

结对编程,代码质量

测试驱动,安全可靠

持续集成,尽早反馈

自动部署,一键安装

定期回顾,持续改进

不断学习,提高能力

```

- 但,正所谓“练拳不练功,到老一场空”。学习招数和套路不难,难的是如何练就一身真功夫。内家功,以练内为主,内外结合,以动作引领内气,以内气催领动作,通过后天的修炼来弥补先天的不足。

- 它注重于北洋软件开发者的态度、原则、操守、价值观,即识、胆、气、劲、神是也。

### 第一章 敏捷——高效软件开发之道

- 不管路走了多远,错了就要重新返回。

- 你要不断从自己写的代码中得到反馈,并且使用自动化工具不断地构建(持续集成)和测试系统。

- 先难后易。我们首先要解决困难的问题,把简单的问题留到最后。

### 第二章 态度决定一切

做事。

- 选定了要走的路,就是选定了它通往的目的地。

- 专业的态度应该着眼于项目和团队的积极结果,关注个人和团队的成长,围绕最后的成功开展工作。

- 只有在你对项目、工作、事业有一个专业的态度时,使用敏捷方法才会生效。

- 他们把精力直接放在解决问题上,而不是抱怨。

- 过程符合标准并不意味着是正确的。

欲速则不达。

- 优秀的程序员会更深挖一层,尽力去理解为什么这里必须要加1,更重要的是,他会想明白会产生什么其他影响。

- 所有的大型系统都非常复杂,因此没有一个人能完全明白所有的代码。

对事不对人。

- 然而,好的软件开发作品和好的软件设计,都需要大量的创造力和洞察力。

- 你必须把重点放在解决问题上,而不是极力去证明谁的主意更好。

- 你不需要很出色才能起步,但是你必须起步才能变得很出色。

- “能欣赏自己并不接受的想法,表明你的头脑足够有学识。” — 亚里士多德

- 工作中不感情用事是需要克制力的,而你若能展现出成熟大度来,大家一定不会视而不见。

排除万难,奋勇前进。

- 绝妙的计划会因为勇气不足而最终失败。

- 你必须有勇气向前冲锋,做你认为对的事情。

- 如果你在压力下对代码质量作出妥协,你可以指出,作为一名开发者,你没有职权毁坏公司的资产(所有的代码)。

### 第三章 学无止境

- 即使你已经在正确的轨道上,但如果只是停止不前,也仍然会被淘汰出局。

跟踪变化。

- 你要正确把握自己投入的精力。

- 在做决策之前,你必须评估新技术的优势。开发一个小的原型系统,是对付技术狂热者的一剂良药。

对团队投资。

- 不同才能和背景的人混在一起,是一个非常理想的学习环境。

- 一个学习型的团队才是较好的团队。

- 优秀的管理者会重用那些能提高其他团队成员价值的人。

- 坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。

懂得丢弃。

- 在学习一门新技术的时候,多问问自己,是否把太多旧的态度和方法用在了新技术上。

- 打破旧习惯很难,更难的是自己还没意识到这个问题。

- 思维定式是经过多年摸爬滚打才构建成型的,已经根深蒂固,没有人可以很容易就丢弃它们。

把握开发节奏。

- 如果在你工作的时候没有一个固定的最终期限(例如一天的结束), 就应该好好想想了。

- 许多的敏捷技巧来源于时间盒——设定一个短时的期限,为任务设定不能延长的最终期限。你可以选择放弃其他方面的任务,但是最终期限是不变的。你可能不知道完成所有任务需要多少个时间盒,但每个时间盒必须是短期的、有限的,并且要完成具体的目标。

- 鲨鱼必须不停地向前游,否则就会死亡。在这方面,软件项目就像是鲨鱼,你需要不停地前进,同时要清楚自己的真实进度。

- 如果开发节奏过于密集,你会精疲力竭的。一般来说,当与其他团队合作时,你需要减慢开发节奏。因此人们常说,互联网时代发展太快,有害健康。

交付用户想要的软件。

- 软件开发如战争,形势的变化快速而又剧烈。

- 使用短迭代,增量开发来帮助经常发布新功能,与用户的需求变化联系更紧密。

- 固定的价格就意味着背叛承诺。

让设计指导而不是操纵开发。

- 设计可以分为两层:战略和战术。前期的设计属于战略,通常只有在没有深入理解需求的时候需要这样的设计。更确切的说,它应该只描述总体战略,不应深入到具体的细节。

- 即使初始的设计到后面不管用,你仍需要设计:设计行为是无价的。正如美国总统艾森豪威尔所说:“计划是没有价值的,但计划的过程是必不可少的。”在设计过程中学习是有价值的,但设计本身也许没有太大的用处。

- 白板、草图、便利贴都是非常好的设计工具。复杂的建模工具只会让你分散精力,而不是启发你的工作。

合理地使用技术。

- 你的代码写得越少,需要维护的东西就越少。

- 新技术就应该像是新的工具,可以帮助你更好地工作,它自己不应该成为你的工作。

- 如果你还没有足够的经验,不要急于决定使用什么技术。

- 不要开发那些你容易下载到的东西。虽然有时需要从最基础开发所有你需要的东西,但那是相当危险和昂贵的。

保持可以发布。

- 你有一个持续集成系统,可以自动集成并报告集成成果。

提早集成,频繁集成。

- 使用mock对象,它更容易控制,能够模仿需要的行为,使测试更加简单。

提早自动化部署。

使用演示获得频繁反馈。

- 没有人的思想和观点可以及时冻结,特别是项目的客户。

使用短迭代,增量发布。

- 软件开发不是精细化的制造业,而是创新活动。

- 对付大项目,最理想的办法就是小步前进,这也是敏捷方法的核心。

固定的价格就意味着背叛承诺。

- 主动提议先构建系统最初的、小的和有用的部分。挑选一系列小的功能,这样完成第一次交付应该不多于6~8周。向客户解释,这时候还不是要完成所有的功能,而是足够一次交付,并能让用户真正使用。

- 你的评估数据会在整个项目中发生变化——它们不是固定的。但是,你会觉得自信心在不断增加,你会越来越清楚每个迭代可以完成的工作。随着时间的推移,你的评估能力会不断地提高。

- 如果你对答案不满意,那么看看你是否可以改变问题。

- 如果你在完成第一个迭代开发之前,拒绝做任何评估,也许你会失去这个合同,让位于那些提供了评估的人,无论他们做了多么不切实际的承诺。

### 第五章 敏捷反馈

守护天使。

- coding feedback

- 不要放过任何一个失败的测试。

先用它再实现它。

- 先写测试有助于消除过度复杂的设计,让你可以专注于真正需要完成的工作。

- 什么是成功地实现特定功能的最低成本。

- Good design doesn’t mean more classes.

自动验收测试。

- 关键业务逻辑必须要独立进行严格的测试,并且最后需要通过用户的审批。

度量真实的进度。

- 判断工作进度最好是看实际花费的时间而不是估计的时间。

- 这里诚实非常重要,隐瞒真相毫无意义。

- 关注功能,而不是日程表。

- 一周工作40个小时,不是说你就有40个小时的编码时间。

倾听用户的声音。

- 对客户的那些愚蠢抱怨,你既不会生气,也不会轻视。你会查看一下,找出背后真正的问题。

- “它就是这样的。”这不是一个好的答案。

### 第六章 敏捷编码

- "任何一个笨蛋都能够让事情变得越来越笨重,越来越复杂、越来越极端。需要天才的指点以及许多的勇气,才能让事情向相反的方向发展。 “ —John Dryden

- 想写出简单的代码要远比写出令人厌恶的、过分复杂的代码难得多。

- 开发代码时,应该更注重可读性,而不是只图自己方便。代码阅读的次数要远远超过编写的次数,所以在编写的时候值得花点功夫让它读起来更加简单。实际上,从衡量标准来看,代码清晰程度的优先级应该排在执行效率之前。

- 在编写代码时,应该使用语言特性来提升表现力。

- 不要明日复明日。如果现在不做的话,以后你也不会做的。

保持简单。

- 不要让自己被迫进行过分设计,也不要将代码过分复杂化。

- 许多开发人员倾向于将投入的努力与程序复杂性混同起来。

- 开发人员更应该为自己能够创造出一个简单并且可用的设计而骄傲。

- 优雅的代码第一眼看上去,就知道它的用处,而且很简洁。但是这样的解决方案不是那么容易想出来的。这就是说,优雅是易于理解和辨识的,但是要想创建出来就困难得多了。

- 告知,不要询问。不要抢别的对象或者是组件的工作。告诉它做什么,然后盯着你自己的职责就好了。

### 第七章 敏捷调试

- 你也许会对木匠那毫无差错的工作印象深刻。但我向你保证,事实不是这样的。真正的高手只是知道如何亡羊补牢。 -- jeff Miller,家具制造者,作家

- 维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分,以后发生相同或类似问题时,就可以很快找到并使用了。

- 将警告视为错误。签入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样,都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。

对问题各个击破。

- 单元测试带来的积极效应之一,是它会强迫形成代码的分层。如果不是这样,你会发现自己在修改bug之前,就已经陷入到整个系统中,徒然增加了压力,而且降低了工作效率。

- 在这些状况下,最好花一些时间把关注的代码提取出来,而且创建一个可让其工作的测试环境。

报告所有的异常。

- 像java中那样的检查异常会强迫你捕捉异常,或是把异常传播出去。

- 处理或者是向上传播所有的异常。不要将它们压制不管,就算是临时这样做也不行。在写代码时要估计到会发生的问题。

- 决定由谁来负责处理异常是设计工作的一部分。

定期安排会面时间。

- 要保证会议议题不会发散,每个人都应该只回答下述三个问题。

```

昨天由什么收获?

今天计划要做哪些工作?

面临着哪些障碍?

```

- 只能给予每个参与者很少的发言时间(大约两分钟)。

实行代码集体所有制。

- 任何人都可能遭遇到诸如车祸等突发的灾难事故,或者有可能被竞争对手雇佣。如果不向整个团队分享知识,反而增加了丧失知识的风险。

成为指导者。

- 为团队成员在寻求帮助之前陷入某个问题的时间设定一个时限,一个小时应该是不错的选择。

允许大家自己想办法。

- 用问题来回答问题,可以引导提问的人走上正确的道路。

做代码复查。

- 代码刚刚完成时,是寻找问题的最佳时机。

- 代码复查随着开发活动持续进行,而且每次针对的代码量相对较少。感觉复查就像是项目正在进行的一部分,而不是一种令人畏惧的事情。

及时通报进展与问题。

- 及时通报进展与问题,有情况发生时,就不会让别人感到突然,而且他们也很愿意了解目前的进展状况。

- 当经理或同事来询问工作进展、最新的设计、或研究状况时,不会感到头痛。

0
《高效程序员的45个习惯》的全部笔记 106篇
豆瓣
我们的精神角落
免费下载 iOS / Android 版客户端