出版社: 人民邮电出版社
副标题: 敏捷开发修炼之道
译者: 钱安川 / 郑柯
出版年: 2010-01
页数: 204
定价: 35.00元
装帧: 平装
丛书: 图灵程序设计丛书·程序员修炼系列
ISBN: 9787115215536
内容简介 · · · · · ·
“书中‘切身感受’的内容非常有价值——通过它我们可以做到学有所思,思有所悟,悟有所行。”
——Nathaniel T. Schutta,《Ajax基础教程》作者
“此书通过常理和经验,阐述了为什么你应该在项目中使用敏捷方法。最难得的是,这些行之有效的实战经验,竟然从一本书中得到了。”
——Matthew Johnson,软件工程师
十年来,软件行业发生了翻天覆地的变化。敏捷方法大行其道,测试和测试驱动开发在很多开发人员的工作中扮演着重要的角色。作为一名程序员,你应该培养怎样的素质,方能对多变的环境应对自如,始终立于不败之地?
本书简明实用、见解深刻,总结了高效程序员在开发过程中的45个个人习惯、思想观念和方法,有助于开发人员在开发进程、编码工作、开发者态度、项目和团队管理,以及持续学习等5个方面积极修炼。通过学习这些内容,养成这些好的习惯,你可以极大...
“书中‘切身感受’的内容非常有价值——通过它我们可以做到学有所思,思有所悟,悟有所行。”
——Nathaniel T. Schutta,《Ajax基础教程》作者
“此书通过常理和经验,阐述了为什么你应该在项目中使用敏捷方法。最难得的是,这些行之有效的实战经验,竟然从一本书中得到了。”
——Matthew Johnson,软件工程师
十年来,软件行业发生了翻天覆地的变化。敏捷方法大行其道,测试和测试驱动开发在很多开发人员的工作中扮演着重要的角色。作为一名程序员,你应该培养怎样的素质,方能对多变的环境应对自如,始终立于不败之地?
本书简明实用、见解深刻,总结了高效程序员在开发过程中的45个个人习惯、思想观念和方法,有助于开发人员在开发进程、编码工作、开发者态度、项目和团队管理,以及持续学习等5个方面积极修炼。通过学习这些内容,养成这些好的习惯,你可以极大地提升自己的编程实力,更快速、更可靠地交付更高质量的软件,从而成为真正的高效程序员。
作者简介 · · · · · ·
Venkat Subramaniam博士
Agile Developer公司创始人,敏捷开发权威人士。他培训并指导了美国、加拿大、印度和欧洲多国的上千名软件开发人员,并多次在各种大会上发表演讲。他还是.NET Gotchas的作者。可以通过venkats@agiledeveloper.com与他联系。
Andy Hunt
敏捷开发权威人士,敏捷宣言的创始人,Pragmatic Programmers公司创始人。除了本书,他还是多本获奖和备受好评图书的合著者,这些图书包括Programming Ruby、《程序员修炼之道——从小工到专家》、《单元测试之道C#版——使用NUnit 》、《单元测试之道Java版——使用JUnit》、《版本控制之道——使用CVS 》等。
目录 · · · · · ·
第2章 态度决定一切
1. 做事
2. 欲速则不达
3. 对事不对人
4. 排除万难,奋勇前进
第3章 学无止境
5. 跟踪变化
6. 对团队投资
7. 懂得丢弃
8. 打破砂锅问到底
9. 把握开发节奏
第4章 交付用户想要的软件
10. 让客户做决定
11. 让设计指导而不是操纵开发
12. 合理地使用技术
13. 保持可以发布
14. 提早集成,频繁集成
15. 提早实现自动化部署
16. 使用演示获得频繁反馈
17. 使用短迭代,增量发布
18. 固定的价格就意味着背叛承诺
第5章 敏捷反馈
19. 守护天使
20. 先用它再实现它
21. 不同环境,就有不同问题
22. 自动验收测试
23. 度量真实的进度
24. 倾听用户的声音
第6章 敏捷编码
25. 代码要清晰地表达意图
26. 用代码沟通
27. 动态评估取舍
28. 增量式编程
29. 保持简单
30. 编写内聚的代码
31. 告知,不要询问
32. 根据契约进行替换
第7章 敏捷调试
33. 记录问题解决日志
34. 警告就是错误
35. 对问题各个击破
36. 报告所有的异常
37. 提供有用的错误信息
第8章 敏捷协作
38. 定期安排会面时间
39. 架构师必须写代码
40. 实行代码集体所有制
41. 成为指导者
42. 允许大家自己想办法
43. 准备好后再共享代码
44. 做代码复查
45. 及时通报进展与问题
第9章 尾声:走向敏捷
9.1 只要一个新的习惯
9.2 拯救濒临失败的项目
9.3 引入敏捷:管理者指南
9.4 引入敏捷:程序员指南
9.5 结束了吗
附录A 资源
索引
· · · · · · (收起)
原文摘录 · · · · · · ( 全部 )
-
敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善。 指责不会修复bug,应把矛头指向问题的解决办法,而不是人。 不用要急于修复一段没能理解的代码。 对事不对人。 消极的评论会扼杀创新,脱离实际的反方观点会使争论变味。 试用VS2010:但之前要确定几个问题:1只有它才能最好的解决当前问题吗2你将会被它栓住吗3维护成本是多少 五个为什么很有用,但要问到点子上,不要跑题。 设计是用于指导开发的,而不是牵制开发。敏捷并不意味着不设计,比如用uML画关键工作图:使用类及其交互关系来描绘系统是如何组织的。 保持项目随时可以发布:编译,运行,测试并立即部署。 提早集成,持续而有规律的频繁集成。 在没有询问或征得用户的同意之前,安装程序绝对不能删除用户的数据。用户应该可以安全并完整的地卸载软件。 不一致的术语是导致需求误解的一个主要原因。应该维护一个术语表。 对用户(产品经理)使用演示来获得频繁反馈。 使用短迭代,增量发布。 要强调代码的集体所有制,让开发人员轮换完成系统不同领域中不同模块的不同任务。但也不用无意间丧失了团队的专家技能。开发人员不必了解每个细节,但是也不能因为要处理某个模块的代码而感到惊恐。 好的想法不会因为被许多人了解而削弱。如果你用你的蜡烛点燃了别人的,别人在得到光明的同时,也没有让你的周围变暗。 作为指导者,应该鼓励、引领大家思考如何解决问题,并给大家解决问题的机会,而不是只告诉答案,除非对方真的陷入胶着状态。 代码复查对于提升代码质量和降低错误率的重要作用。需要积极评估代码的设计和清晰程度,而不止是考量变量名和代码格式是否符合组织的标准。当某些代码编写完成、通过编译、完成测试,并已经准备签入时,其他开发人员就可以“捡拾”起这些代码开始复查。当然,更好的方法是编程时就结对。要确保复查人员得到每次复查活动的反馈结果。 如果要将团队带入新的领域,必须... (查看原文) —— 引自章节:全书 -
软件项目的成败,依赖于整个项目团队中所有开发成员的技术水平,对他们的培训,以及他们各自的能力高低。 (查看原文) —— 引自第1页
> 全部原文摘录
丛书信息
喜欢读"高效程序员的45个习惯"的人也喜欢的电子书 · · · · · ·
喜欢读"高效程序员的45个习惯"的人也喜欢 · · · · · ·
高效程序员的45个习惯的话题 · · · · · · ( 全部 条 )



高效程序员的45个习惯的书评 · · · · · · ( 全部 42 条 )
> 更多书评 42篇
-
1. 对团队投资 2. 提早实现自动化部署 3. 固定价格就意味着背叛承诺 4. 代码要清晰地表达意图 5. 编写内聚的代码 6. 告知,不要询问 [http://robots.thoughtbot.com/post/27572137956/tell-dont-ask] 7. Liskov替换原则 [http://zh.wikipedia.org/wiki/Liskov%E4%BB%A3%E6%8F%9B%E5%8E%9F%E5%89%87] 8. 记录问题解决日志
2012-11-26 22:12 1人喜欢
1. 对团队投资 2. 提早实现自动化部署 3. 固定价格就意味着背叛承诺 4. 代码要清晰地表达意图 5. 编写内聚的代码 6. 告知,不要询问 http://robots.thoughtbot.com/post/27572137956/tell-dont-ask 7. Liskov替换原则 http://zh.wikipedia.org/wiki/Liskov%E4%BB%A3%E6%8F%9B%E5%8E%9F%E5%89%87 8. 记录问题解决日志
回应 2012-11-26 22:12 -
看到厨房很脏,去清理一下,总比等到油污沉积再去打扫省力得多。这就是敏捷开发,小步迭代,快速交付,聆听反馈,积极重构的意义。 写一段代码就测试,重构,休息。让代码干净利落 定期安排会面时间,常开会,开短会 控制好时间,养成好习惯,不要加班 主动及时通报进展及问题,不要等人来问 代码要清晰的表达意图,标准是不需要注释也能可读。方法包括:用枚举代替数字 编写清晰而不是讨巧的代码 不要明日复明日,如果现在不做...
2019-04-08 12:25
看到厨房很脏,去清理一下,总比等到油污沉积再去打扫省力得多。这就是敏捷开发,小步迭代,快速交付,聆听反馈,积极重构的意义。
写一段代码就测试,重构,休息。让代码干净利落
定期安排会面时间,常开会,开短会
控制好时间,养成好习惯,不要加班
主动及时通报进展及问题,不要等人来问
代码要清晰的表达意图,标准是不需要注释也能可读。方法包括:用枚举代替数字
编写清晰而不是讨巧的代码
不要明日复明日,如果现在不做的话,以后也不会做的
可配置变量太多,会导致代码维护及新增困难
一个应用需要从数据库中读取数据并显示在前端,这里有两种做法:
1. 从数据库读取数据,创建对象,返回UI,在UI再拆分。
2. 数据库中做个view,UI直接读
在硬件上多投入以换取性能提升,降低开发成本与缩短上市时间
客户决定将重点放在哪里
保留以前的问题解决方案,以及提供发生问题时更多的有用细节。要想更加有效的重用你的知识,记录问题解决日志是很有用的
面对问题,并解决它们,是开发人员的生活方式。如果一个熟悉的问题再次发生,我们需要记起第一次是如何解决掉的,而且希望这一次能更快地搞定
维护一个保存曾遇到的问题以及对应解决方案的日志。当问题发生时,快速搜索(day log, do not get burned twice!
day log: 日期,问题,发生问题的版本,平台或版本,代码,原因,解决方案,引用。并可供搜索,excel
共享日志给其他人,创建wiki,鼓励其他开发人员使用和更新其内容。维护一个问题及解决方案的日志
解决方案日志应该作为思考的一个来源,可以在其中发现某些特定问题的细节。对于某些相似又有差异的问题,也能从中获得修复的指引
记录问题的时间不能超过在解决问题上花费的时间,要保持轻量和简单
关注编译错误和警告,⚠️出现时也必须停下来,解决掉再继续。比如一个未使用变量的警告,可能意味着其他变量被错误使用了
让IDE的编译器VS,Eclipse将警告作为错误提示出来,不让任何警告被忽略
要保证代码可测试,必须把他从周边的代码中解脱出来。如果代码依赖其他模块,就应该使用mock对象,来将它从其他模块中分离开
在向问题发起攻击之前,先查找你的解决问题日志
处理或者向上传播所有异常,不要将他们压制并keep在自己手里
当发生问题时,让应用详细记录错误的相关数据。错误日志最起码应该以文本的形式维护。或发送到一个系统级别的事件日志,可以使用工具来浏览日志,产生所有日志信息的RSS feed
对于不幸的用户来说,他们一点头绪都没有,不知道自己到底做错了什么,给技术支持打电话时,应该报告点什么
一条好的用户错误警告,应该包含清晰,易于理解的问题描述和解释,详细技术细节可以一个uuid标志。当客户遇到问题时,自动发送信息给支持团队,而支持团队通过uuid查找详细日志记录
程序员在拒绝设计的同时,也就放弃了思考
强调代码的集体所有制,然后开发人员轮换完成系统中不同领域,不同模块的不同任务
及时提交代码,每个提交具有原子性,链接jira作为回溯和查找修改原因及内容,便于回滚,分析问题及扩展开发。绝对不要提交没有完成的代码
code review代码复查非常重要。每个程序员都应该这么做
code review可以遵循一些原则,或基本列表:
所有的异常处理程序不允许为空,所有数据库调用都要包在事物中进行
及时通报进展与问题,有情况发生时,就不会让别人感到突然,而且他们也很愿意了解目前的进展状况,他们会知道何时应该提供帮助,而且你也获得了他们的信任
在slack channel 里早上发todo list,晚上发status updates.有问题时raise出来,notify others to get a chance to have a look on it 发布进展状况,新的想法和目前正在关注的主题,不要等着别人来问项目状态如何
经常抬头看看四周,而不只埋头于自己的工作
回应 2019-04-08 12:25
-
1. 对团队投资 2. 提早实现自动化部署 3. 固定价格就意味着背叛承诺 4. 代码要清晰地表达意图 5. 编写内聚的代码 6. 告知,不要询问 [http://robots.thoughtbot.com/post/27572137956/tell-dont-ask] 7. Liskov替换原则 [http://zh.wikipedia.org/wiki/Liskov%E4%BB%A3%E6%8F%9B%E5%8E%9F%E5%89%87] 8. 记录问题解决日志
2012-11-26 22:12 1人喜欢
1. 对团队投资 2. 提早实现自动化部署 3. 固定价格就意味着背叛承诺 4. 代码要清晰地表达意图 5. 编写内聚的代码 6. 告知,不要询问 http://robots.thoughtbot.com/post/27572137956/tell-dont-ask 7. Liskov替换原则 http://zh.wikipedia.org/wiki/Liskov%E4%BB%A3%E6%8F%9B%E5%8E%9F%E5%89%87 8. 记录问题解决日志
回应 2012-11-26 22:12 -
-
敏捷的特点是迭代和反馈。其目的是做正确的事,而不是将事情做正确。 其实看下一些最近几年内火的东西。比如facebook很大程度上是敏捷开发。在比如小说的连载的形式,亦是每天写一下段,然后再根据读者的反馈进行相应的调整。再比如连载的漫画和美剧。 书中有些东西是为了写出质量高的代码。比如可读性。 好的习惯可以使自己有更多的精力去做关键的事情。习惯是工具不是目的。
2013-04-10 20:43
-
看到厨房很脏,去清理一下,总比等到油污沉积再去打扫省力得多。这就是敏捷开发,小步迭代,快速交付,聆听反馈,积极重构的意义。 写一段代码就测试,重构,休息。让代码干净利落 定期安排会面时间,常开会,开短会 控制好时间,养成好习惯,不要加班 主动及时通报进展及问题,不要等人来问 代码要清晰的表达意图,标准是不需要注释也能可读。方法包括:用枚举代替数字 编写清晰而不是讨巧的代码 不要明日复明日,如果现在不做...
2019-04-08 12:25
看到厨房很脏,去清理一下,总比等到油污沉积再去打扫省力得多。这就是敏捷开发,小步迭代,快速交付,聆听反馈,积极重构的意义。
写一段代码就测试,重构,休息。让代码干净利落
定期安排会面时间,常开会,开短会
控制好时间,养成好习惯,不要加班
主动及时通报进展及问题,不要等人来问
代码要清晰的表达意图,标准是不需要注释也能可读。方法包括:用枚举代替数字
编写清晰而不是讨巧的代码
不要明日复明日,如果现在不做的话,以后也不会做的
可配置变量太多,会导致代码维护及新增困难
一个应用需要从数据库中读取数据并显示在前端,这里有两种做法:
1. 从数据库读取数据,创建对象,返回UI,在UI再拆分。
2. 数据库中做个view,UI直接读
在硬件上多投入以换取性能提升,降低开发成本与缩短上市时间
客户决定将重点放在哪里
保留以前的问题解决方案,以及提供发生问题时更多的有用细节。要想更加有效的重用你的知识,记录问题解决日志是很有用的
面对问题,并解决它们,是开发人员的生活方式。如果一个熟悉的问题再次发生,我们需要记起第一次是如何解决掉的,而且希望这一次能更快地搞定
维护一个保存曾遇到的问题以及对应解决方案的日志。当问题发生时,快速搜索(day log, do not get burned twice!
day log: 日期,问题,发生问题的版本,平台或版本,代码,原因,解决方案,引用。并可供搜索,excel
共享日志给其他人,创建wiki,鼓励其他开发人员使用和更新其内容。维护一个问题及解决方案的日志
解决方案日志应该作为思考的一个来源,可以在其中发现某些特定问题的细节。对于某些相似又有差异的问题,也能从中获得修复的指引
记录问题的时间不能超过在解决问题上花费的时间,要保持轻量和简单
关注编译错误和警告,⚠️出现时也必须停下来,解决掉再继续。比如一个未使用变量的警告,可能意味着其他变量被错误使用了
让IDE的编译器VS,Eclipse将警告作为错误提示出来,不让任何警告被忽略
要保证代码可测试,必须把他从周边的代码中解脱出来。如果代码依赖其他模块,就应该使用mock对象,来将它从其他模块中分离开
在向问题发起攻击之前,先查找你的解决问题日志
处理或者向上传播所有异常,不要将他们压制并keep在自己手里
当发生问题时,让应用详细记录错误的相关数据。错误日志最起码应该以文本的形式维护。或发送到一个系统级别的事件日志,可以使用工具来浏览日志,产生所有日志信息的RSS feed
对于不幸的用户来说,他们一点头绪都没有,不知道自己到底做错了什么,给技术支持打电话时,应该报告点什么
一条好的用户错误警告,应该包含清晰,易于理解的问题描述和解释,详细技术细节可以一个uuid标志。当客户遇到问题时,自动发送信息给支持团队,而支持团队通过uuid查找详细日志记录
程序员在拒绝设计的同时,也就放弃了思考
强调代码的集体所有制,然后开发人员轮换完成系统中不同领域,不同模块的不同任务
及时提交代码,每个提交具有原子性,链接jira作为回溯和查找修改原因及内容,便于回滚,分析问题及扩展开发。绝对不要提交没有完成的代码
code review代码复查非常重要。每个程序员都应该这么做
code review可以遵循一些原则,或基本列表:
所有的异常处理程序不允许为空,所有数据库调用都要包在事物中进行
及时通报进展与问题,有情况发生时,就不会让别人感到突然,而且他们也很愿意了解目前的进展状况,他们会知道何时应该提供帮助,而且你也获得了他们的信任
在slack channel 里早上发todo list,晚上发status updates.有问题时raise出来,notify others to get a chance to have a look on it 发布进展状况,新的想法和目前正在关注的主题,不要等着别人来问项目状态如何
经常抬头看看四周,而不只埋头于自己的工作
回应 2019-04-08 12:25 -
9.3引入敏捷:管理者指南9.4引入敏捷:程序员指南西方谚语,原文为:Youcanleadahorsetowater,butyoucannotmakehimdrink(你可以带马到水边,但不能免强它喝水),其意指:善意不足以成事。[][]附录A 资源Unix编程艺术[http://www.faqs.org/docs/artu/ch04s02.htmlEricStevenRaymond]的《Unix编程艺术》一书节选。 一灯能除千年暗,一智能灭万年愚。——慧能,中国禅宗第6代祖师[][]架构师必须写代码 ①第一次世界大战中,所门...
2018-10-10 15:47
9.3引入敏捷:管理者指南9.4引入敏捷:程序员指南西方谚语,原文为:Youcanleadahorsetowater,butyoucannotmakehimdrink(你可以带马到水边,但不能免强它喝水),其意指:善意不足以成事。[][]附录A 资源Unix编程艺术http://www.faqs.org/docs/artu/ch04s02.htmlEricStevenRaymond的《Unix编程艺术》一书节选。 一灯能除千年暗,一智能灭万年愚。——慧能,中国禅宗第6代祖师[][]架构师必须写代码 ①第一次世界大战中,所门战役(theBattleoftheSomme)本应成为一个有决定性意义的突破。实际上,它却成为了20世纪最愚蠢的军事行动。最重要的原因是,由于断绝了通信联系,面对的战场情况与早先的预测已经完全不同了,指挥官仍然坚持按照原计划展开战役。请查看http://www.worldwar1.com/sfsomme.htm。 Youcan’tcodeinPowerPoint“ PowerPoint架构师”[][]复查 代码刚刚完成时,是寻找问题的最佳时机。如果放任不管,它也不会变得更好。代码复查和缺陷移除要寻找深藏不露的程序bug,正式地进行代码检查,其效果是任何已知形式测试的两倍,而且是移除80%缺陷的唯一已知方法。——CapersJones的《估算软件成本》[Jon98]
- 代码能否被读懂和理解?
- 是否有任何明显的错误?
- 代码是否会对应用的其他部分产生不良影响?
- 是否存在重复的代码(在复查的这部分代码中,或是在系统的其他部分代码)?
- 是否存在可以改进或重构的部分?此外,还可以考虑使用诸如SimilarityAnalyzer或Jester这样的代码分析工具。
[][]33记录问题解决日志“在开发过程中是不是经常遇到似曾相识的问题?这没关系。以前解决过的问题,现在还是可以解决掉的。”Don’tgetburnedtwice
- 问题发生日期。
- 问题简述。
- 解决方案详细描述。
- 引用文章或网址,以提供更多细节或相关信息。
- 任何代码片段、设置或对话框的截屏,只要它们是解决方案的一部分,或者可以帮助更深入地理解相关细节。
你也许会对木匠那毫无差错的工作印象深刻。但我向你保证,事实不是这样的。真正的高手只是知道如何亡羊补牢。——JeffMiller,家具制造者、作家代码要清晰地表达意图“可以工作而且易于理解的代码当然好,但是让人觉得聪明更加重要。别人给你钱是因为你脑子好使,让我们看看你到底有多聪明。 ”PIE④原则④PIE=ProgramIntentlyandExpressively,即意图清楚而且表达明确地编程。——编者注代码必须明确说出你的意图,而且必须富有表达力。这样可以让代码更易于被别人阅读和理解。代码不让人迷惑,也就减少了发生潜在错误的可能。一言以蔽之,代码应意图清晰,表达明确。[]用注释沟通。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。
- 在代码可以传递意图的地方不要使用注释。
- 解释代码做了什么的注释用处不那么大。相反,注释要说明为什么会这样写代码。
- 当重写方法时,保留描述原有方法意图和约束的注释。
[][]增量式编程 所开发的代码基于即时的反馈,这些反馈来自以小步幅方式编写代码和测试的过程。采取增量式编程和测试,会倾向于创建更小的方法和更具内聚性的类。在写了几行代码之后,你会迫切地希望进行一次构建/测试循环。在没有得到反馈时,你不想走得太远。[]编写内聚的代码内聚性用来评估一个组件(包、模块或配件)中成员的功能相关性。内聚程度高,表明各个成员共同完成了一个功能特性或是一组功能特性。内聚程度低的话,表明各个成员提供的功能是互不相干的。让类的功能尽量集中,让组件尽量小。很多成功的公司都是靠着“吃自己的狗食”活着。也就是说,如果要让你的产品尽可能地好,自己先要积极地使用它。[][]23度量真实的进度 专注于你的方向Focusonwhereyou’regoing如果你最初估计这个任务需要40个小时,在开发了35个小时之后,你认为还需要另外30个小时的工作。那就得到了很重要的度量结果(这里诚实非常重要,隐瞒真相毫无意义)。 待办事项(backlog)的好处[]7懂得丢弃敏捷的根本之一就是拥抱变化。既然变化是永恒的,你有可能一直使用相同的技术和工具吗?不,不可能。我们一直在本章说要学习新技术和新方法。但是记住,你也需要学会如何丢弃。
- 根深蒂固的习惯不可能轻易地就丢弃掉
Expensivementalmodelsaren’tdiscardedlightly学习新的东西,丢弃旧的东西。在学习一门新技术的时候,要丢弃会阻止你前进的旧习惯。毕竟,汽车要比马车车厢强得多。新技术会让人感到有一点恐惧。你确实需要学习很多东西。已有的技能和习惯为你打下了很好的基础,但不能依赖它们。
- 对于所使用的语言,要总结熟悉的语言特性,并且比较这些特性在新语言或新版本中有什么不同。
回应 2018-10-10 15:47
论坛 · · · · · ·
有没有人比较过此书和《程序员修炼之道》? | 来自Roy | 1 回应 | 2011-11-10 |
同样是敏捷,能将其描述的实际详实是关键之举 | 来自Yuheng | 2010-09-27 | |
此书甚好 | 来自豆他爹 | 1 回应 | 2010-09-25 |
这本书的其他版本 · · · · · · ( 全部3 )
-
Oreilly & Associates Inc (2006)8.6分 47人读过
-
人民邮电出版社 (2014)7.7分 43人读过
以下书单推荐 · · · · · · ( 全部 )
谁读这本书?
二手市场
订阅关于高效程序员的45个习惯的评论:
feed: rss 2.0
0 有用 透明 2010-08-26
没有太多新东西。我想看的不是“有哪些好习惯”,而是“如何选择哪些好习惯”。可惜,没有。
0 有用 r2g2 2010-06-29
infoq 精选版
2 有用 丸子(^.^)v 2010-11-22
个人体会是 水平得高 实现技术得熟练~ 然后这些就好上手~ 留着看10年后的自己会不会来笑自己……
1 有用 f234f234 2013-11-14
若已对敏捷有所了解,那么此书除了插科打诨外实在没有什么新意。
0 有用 hushlight 2014-04-03
这是本充满了“正确的话”的书,如果已经有敏捷开发经验的话,可能会觉得此书太浅;如果没有经验的话,不知道能吸收多少
0 有用 靖 2021-03-06
对于敏捷很有实用性的书。
0 有用 Eazow 2021-02-09
习惯改变行为,行为决定命运。里面的习惯还是很推荐学习下,指导日常的编程工作
0 有用 萧文翰 2021-01-26
一天看三个,两周左右看完。 值得一看再看。
0 有用 某某CHI 2021-01-14
有一些观点对我还是很有帮助的。
0 有用 国王KING 2020-11-19
ASD是一系列工作方法。