高效程序员的45个习惯

高效程序员的45个习惯

敏捷开发修炼之道

8.21190 评价豆瓣读书
免费试读

作品简介

本书简明实用、见解深刻,总结了高效程序员在开发过程中的45个个人习惯、思想观念和方法,有助于开发人员在开发进程、编码工作、开发者态度、项目和团队管理,以及持续学习等5个方面积极修炼。通过学习这些内容,养成这些好的习惯,你可以极大地提升自己的编程实力,更快速、更可靠地交付更高质量的软件,从而成为真正的高效程序员。

“书中‘切身感受’的内容非常有价值——通过它我们可以做到学有所思,思有所悟,悟有所行。”

——Nathaniel T. Schutta,《Ajax基础教程》作者

“此书通过常理和经验,阐述了为什么你应该在项目中使用敏捷方法。最难得的是,这些行之有效的实战经验,竟然从一本书中得到了。”

——Matthew Johnson,软件工程师

Venkat Subramaniam

Agile Developer公司创始人,敏捷开发权威人士。他培训并指导了美国、加拿大、印度和欧洲多国的上千名软件开发人员,并多次在各种大会上发表演讲。他还是.NET Gotchas的作者。可以通过venkats@agiledeveloper.com与他联系。

Andy Hunt

敏捷开发权威人士,敏捷宣言的创始人,Pragmatic Programmers公司创始人。除了本书,他还是多本获奖和备受好评图书的合著者,这些图书包括Programming Ruby、《程序员修炼之道——从小工到专家》、《单元测试之道C#版——使用NUnit 》、《单元测试之道Java版——使用JUnit》、《版本控制之道——使用CVS 》等。

作品目录

  1. 版权声明
  2. 译者序
  3. 推荐序一
  4. 推荐序二
  5. 对本书的赞誉
  6. 第1章 敏捷——高效软件开发之道
  7. 第2章 态度决定一切
  8. 1 做事
  9. 2 欲速则不达
  10. 3 对事不对人
  11. 4 排除万难,奋勇前进
  12. 第3章 学无止境
  13. 5 跟踪变化
  14. 6 对团队投资
  15. 7 懂得丢弃
  16. 8 打破砂锅问到底
  17. 9 把握开发节奏
  18. 第4章 交付用户想要的软件
  19. 10 让客户做决定
  20. 11 让设计指导而不是操纵开发
  21. 12 合理地使用技术
  22. 13 保持可以发布
  23. 14 提早集成,频繁集成
  24. 15 提早实现自动化部署
  25. 16 使用演示获得频繁反馈
  26. 17 使用短迭代,增量发布
  27. 18 固定的价格就意味着背叛承诺
  28. 第5章 敏捷反馈
  29. 19 守护天使
  30. 20 先用它再实现它
  31. 21 不同环境,就有不同问题
  32. 22 自动验收测试
  33. 23 度量真实的进度
  34. 24 倾听用户的声音
  35. 第6章 敏捷编码
  36. 25 代码要清晰地表达意图
  37. 26 用代码沟通
  38. 27 动态评估取舍
  39. 28 增量式编程
  40. 29 保持简单
  41. 30 编写内聚的代码
  42. 31 告知,不要询问
  43. 32 根据契约进行替换
  44. 第7章 敏捷调试
  45. 33 记录问题解决日志
  46. 34 警告就是错误
  47. 35 对问题各个击破
  48. 36 报告所有的异常
  49. 37 提供有用的错误信息
  50. 第8章 敏捷协作
  51. 38 定期安排会面时间
  52. 39 架构师必须写代码
  53. 40 实行代码集体所有制
  54. 41 成为指导者
  55. 42 允许大家自己想办法
  56. 43 准备好后再共享代码
  57. 44 做代码复查
  58. 45 及时通报进展与问题
  59. 第9章 尾声:走向敏捷
  60. 9.1 只要一个新的习惯
  61. 9.2 拯救濒临失败的项目
  62. 9.3 引入敏捷:管理者指南
  63. 9.4 引入敏捷:程序员指南
  64. 9.5 结束了吗
  65. 附录A 资源
  66. 索 引
载入中

热门划线

  1. 敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善。26 人
  2. 先难后易。我们首先要解决困难的问题,把简单的问题留到最后。21 人
  3. 能容纳自己并不接受的想法,表明你的头脑足够有学识。16 人
  4. 不管路走了多远,错了就要重新返回。15 人
  5. 一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法15 人
  6. “你不需要很出色才能起步,但是你必须起步才能变得很出色。”13 人
  7. 不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。12 人
  8. 迭代开发,价值优先分解任务,真实进度站立会议,交流畅通用户参与,调整方向结对编程,代码质量测试驱动,安全可靠持续集成,尽早反馈自动部署,一键安装定期回顾,持续改进不断学习,提高能力10 人
  9. 只关注真正重要的事情,少关注那些占用大量时间而无甚裨益的不重要的事情。10 人
  10. 最高优先级应该是解决问题。10 人
  11. 越早发现问题,就越容易修复问题,所以应该就在此时此刻把问题修复。9 人
  12. 过程符合标准并不意味结果是正确的。敏捷团队重结果胜于重过程。9 人
  13. 指责不会修复bug。把矛头对准问题的解决办法,而不是人。这是真正有用处的正面效应。9 人
  14. 拙劣的代码工人会这样不假思索地改完代码,然后快速转向下一个问题。优秀的程序员会挖掘更深一层,尽力去理解为什么这里必须要加1,更重要的是,他会想明白会产生什么其他影响。9 人
  15. 如果你找人帮忙,却没有人积极响应,那么你应该主动引导对话。解释清楚你想要什么,并清晰地表明你的目的是解决问题,而不是指责他人或者进行争辩。8 人
  16. 优秀的程序员会挖掘更深一层,尽力去理解为什么这里必须要加1,更重要的是,他会想明白会产生什么其他影响。8 人
  17. 千里之堤,溃于蚁穴,大灾难是逐步演化来的。一次又一次的快速修复,每一次都不探究问题的根源,久而久之就形成了一个危险的沼泽地,最终会吞噬整个项目的生命。8 人
  18. 不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。8 人
  19. 跟踪技术变化。你不需要精通所有技术,但需要清楚知道行业的动向,从而规划你的项目和职业生涯。8 人
  20. 严格的需求—设计—代码—测试开发流程源于理想化的瀑布式开发方法,它导致在前面进行了过度的设计。这样在项目的生命周期中,更新和维护这些详细的设计文档变成了主要工作,需要时间和资源方面的巨大投资,却只有很少的回报。我们本可以做得更好。8 人
  21. 敏捷的一个主要特点就是持续开发,而不是三天打鱼两天晒网似地工作8 人
  22. 每一个抱怨的背后都隐藏了一个事实。找出真相,修复真正的问题。8 人
  23. 不管路走了多远,错了就要重新返回。——土耳其谚语7 人
  24. 如果你没有犯过任何错误,就说明你可能没有努力去工作。7 人
  25. 图片: 开发者(及项目经理)能做的一个最重要的决定就是:判断哪些是自己决定不了的,应该让企业主做决定。你不需要自己给业务上的关键问题做决定。7 人
  26. 不要用低级别和没有价值的问题打扰繁忙的业务人员。如果问题对他们的业务没有影响,就应该是没有价值的。□不要随意假设低级别的问题不会影响他们的业务。7 人
  27. 战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节。那应该留到战术设计阶段,它应该在项目开发的时候再具体展开。7 人
  28. 不要开发那些你容易下载到的7 人
  29. 单元测试、持续集成和基于窗口的安装程序7 人
  30. 现实世界中的需求就像是流动着的油墨。7 人
  31. 先用它再实现它。将TDD作为设计工具,它会为你带来更简单更有实效的设计。7 人
  32. 开发代码时,应该更注重可读性,而不是只图自己方便。代码阅读的次数要远远超过编写的次数,所以在编写的时候值得花点功夫让7 人
  33. 个体和交互胜过过程和工具可工作的软件胜过面面俱到的文档客户协作胜过合同谈判响应变化胜过遵循计划6 人
  34. 这意味着你不会在项目结束的时候才开始测试,不会在月底才进行一次系统集成,也不会在一开始编码的时候就停止收集需求和反馈。6 人
  35. 相反,这些活动会贯穿项目的整个生命周期。事实上,只要有人继续使用这个软件,开发就没有真正结束。我们进行的是持续开发、持续反馈。你不需要等到好几个月之后才发现问题:越早发现问题,就越容易修复问题,所以应该就在此时此刻把问题修复。这就是敏捷的重点所在。这种持续前进的开发思想根植于敏捷方法中。它不但应用于软件开发的生命周期,还应用于技术技能的学习、需求采集、产品部署、用户培训等方面。它包括了软件开发各个方面的所有活动。6 人
  36. 敏捷依赖人,而不是依赖于项目的甘特图和里程表。6 人
  37. 软件项目时常伴有时间压力——压力会迫使你走捷径,只看眼前利益。但是,任何一个有经验的开发者都会告诉你,欲速则不达6 人
  38. 迭代和增量式的学习。每天计划用一段时间来学习新技术,它不需要很长时间,但需要经常进行。记下那些你想学习的东西——当你听到一些不熟悉的术语或者短语时,简要地把它记录下来。然后在计划的时间中深入研究它。6 人
  39. pragmaticprogrammer.com6 人
  40. 新技术就应该像是新的工具,可以帮助你更好地工作,它自己不应该成为你的工作。6 人
  41. 提早集成,频繁集成。代码集成是主要的风险来源。要想规避这个风险,只有提早集成,持续而有规律地进行集成。6 人
  42. 有价值的东西——比如回顾、测试、重构,一切有利于团队建设、提高生产力的实践都应该频繁且持续做,然后日积月累就养成了习惯。5 人
  43. 对事不对人5 人
  44. 反馈是敏捷的基础5 人
  45. 你应该把重点放到解决问题上,而不是在指责犯错者上面纠缠。5 人
  46. 作为某段代码的调用者,开发人员绝对不应该基于被调用对象的状态来做出任何决策,更不能去改变该对象的状态。这样的逻辑应该是被调用对象的责任,而不是你的。在该对象之外替它做决策,就违反了它的封装原则,而且为bug提供了滋生的土壤。5 人
  47. 处理或是向上传播所有的异常。不要将它们压制不管,就算是临时这样做也不行。在写代码时要估计到会发生的问题。5 人
  48. □昨天有什么收获?□今天计划要做哪些工作?□面临着哪些障碍?5 人

喜欢「高效程序员的45个习惯」的人也喜欢