高效程序员的45个习惯 8.2分
读书笔记 第1页
Breaker Zhao

以下来自我的 Practices of an Agile Developer 笔记

书籍简介

Practices of an Agile Developer: Working in the Real World, by Andy Hunt, Venkat Subramaniam, published in 2005

中文版:高效程序员的 45 个习惯:敏捷开发修炼之道,2010 出版

本书是 Pragmatic Programmers 系列书籍,作者Andy Hunt 是Pragmatic Programmers 的创始人,也是敏捷宣言的起草人之一,另著有《程序员修炼之道:从小工到专家》、《单元测试之道 C# 版:使用 NUnit》。

相关网站: blogs.pragprog.com pragmaticprogrammer.com

6. 对团队投资

午餐会议

P32. 每个人都比你厉害,那太好了。有动力继续提高自己。

P33. 持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。

7. 懂得丢弃

丢弃旧技术、方法和习惯,那些会影响生产力。现在,程序员的时间是稀缺资源。

不是完全忘记旧方法,而是要根据情况转变习惯。

9. 把握开发节奏

每天结束的时候,没有残留的代码、任务。不要把每天最后的尝试性的代码带到下一天,应重新开始。

P41. 时间盒:设定一个短时的期限,最终期限。不知道完成所有任务需要多少个时间盒,但每个时间盒必须是短期的、有限的,并且要完成具体的目标。如:番茄工作时间管理方法。

10. 让客户做决定

如果业务负责人(通常是客户)回答“我不知道”,也许是他们还没有想到那么远,也许是他们只有看到运行的实物才能评估出结果。

11. 让设计指导而不是操纵开发 [Important]

这是敏捷方法对传统方法,如 统一过程 (UP) 等,最具颠覆性的挑战之一,也体现了敏捷宣言中的:可工作的软件产品胜于面面俱到的文档。

Is Design Dead?, by Martin Fowler,是深入讨论本主题的一篇文章。

不做过度的设计,而非不做设计,请画关键工作图。

设计满足实现即可,不必过于详细。

反面示例:更新和维护详细的设计文档变成了主要工作。

战略设计 vs. 战术设计。CRC:类-职责-协作 卡片的设计方法,应用于战术设计。

P51. 完全无设计情景:深入编码只为了学习或创造原型,随后把这些代码扔掉。

P51. 在设计过程中学习是有价值的,但设计本身也许没有太大的用处。这里指,不可缺少设计过程,但不要巨细。

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

23. 度量真实的进度

如果时间表是为工资会计准备的,那么它就很难真实地反映工作完成状况。

随意用一个比率进行度量,如已完成 80%,是没有意义的。

应该测定还剩下多少工作量没有完成,如:估计用 40 小时,已开发 35 小时,认为还需另外 30 个小时。

待办事项 (backlog)

不要花费很多时间来了解你所花费的时间,而没有足够的时间进行工作。意思是,不要说我已工作了多少小时,而要说我已完成了多少个功能,即关注功能,而不是日程表。

Other Chapters

Ch6. 敏捷编码

25. 代码要清晰地表达意图 26. 用代码沟通 27. 动态评估取舍 28. 增量式编程 29. 保持简单 30. 编写内聚的代码 31. 告知,不要询问 32. 根据契约进行替换

Ch7. 敏捷调试

33. 记录问题解决日志 34. 警告就是错误 35. 对问题各个击破 36. 报告所有的异常 37. 提供有用的错误信息

Ch8. 敏捷协作

38. 定期安排会面时间 39. 架构师必须写代码 40. 实行代码集体所有制 41. 成为指导者 42. 允许大家自己想办法 43. 准备好后再共享代码 44. 做代码复查 45. 及时通报进展与问题

0
《高效程序员的45个习惯》的全部笔记 108篇
豆瓣
免费下载 iOS / Android 版客户端