『高效程序员的45个习惯：敏捷开发修炼之道』读书笔记

以下我近些日子的读书笔记。

这本书在我的Pad上也停留了很久，却一直没有毅力将它完整地看完。

原来在微信群里每天发一小段，一方面与同事们分享，另一方面也是把事情挑起来，接受公众的监督。（因为我做事有虎头蛇尾的臭毛病）

电子书见：http://www.amazon.cn/mn/detailApp?asin=B00ALPRKJ8&tag=baiduiclickcn-23&ref=pz_ic_db_j_5bkindle3175

以下切入主题：

第2章：态度决定一切

敏捷团队依赖于人，依赖热情洋溢的你，而不是项目的甘特图和里程表，以及各种各样冷冰冰的需求文档。所以，每个人的态度至关重要。

1、做事：

指责不会修复Bug，所以在敏捷团队中，大家最重要的是做事，出现了问题，应该把重点放在如何解决问题，而不是在指责和抱怨中喋喋不休。

把矛头对准解决问题的方法而不是人，才是有效的正面效应。

如果你没有犯过错误，说明很有可能是你没有努力工作。//很喜欢这个腔调，程序员是个充满挑战的领域，别怕失败和错误。

过程符合标准不意味着结果就是正确的，敏捷团队重结果胜于重过程。//结果导向。

2、欲速则不达：

不要坠入快速的简单修复中，要投入时间和精力来保持代码的整洁和敞亮。只有理解问题才能真正解决问题。

3、对事不对人：

我们评价需求的优先级，往往是根据提出人的身份地位，而不是需求本身的市场价值和利害关系。（心坎里）……让团队中每个人自由表达观点……让我们骄傲的应该是找到了解决问题的正确方法，而不是谁比谁聪明，谁比谁历害。

4、排除万难，奋勇前进：

有时候，绝妙的计划会因为勇气不足而失败，例如“谁去给猫系铃铛”。

第3章：学无止境

敏捷需要持续不断的学习和充电。能否保持步伐前进？只能取决于你自己。

5、跟踪变化：

唯有变化是永恒的。你不需要精通所有技术，但要清楚行业的动向。通过迭代和增量式学习，让自己跟上时代。

6、对团队投资：

团队中每个人都有不同的能力、经验和技术，各有所长。促进成员之间的分享，打造学习型团队。

可以在任何时间，比如午餐的时候讨论你感兴趣的技术问题。

保持每个人对技术的激情。//工程师文化氛围让大家对工作充满激情。

7、懂得丢弃：

拥抱变化，学习和使用新的技术。

8、打破砂锅问到底：

不停地问为什么，直到你明白问题的真正根源。

9、把握开发节奏：

上帝发明了时间，就是为了防止所有事情同时发生。//非常好的一句话，

设定一个时间盒，它的时间长度固定不变，而承载的需求可以灵活安排，这样最大的好处是项目进度可控。

小且可以达到的目标可以让人全速前进。//目标一定要是可达的！

第4章：交付用户想要的软件

没有任何计划在遇敌之后还能继续执行。我们的敌人不是客户、不是用户、不是队友，也不是领导，而是变化！

10、让客户做决定：

开发者不要对业务功能做任何决定。把问题交给业务负责人。

//不过，对于小的团队，我们不做决定，但可以提建议，不是吗？每个人都是产品经理嘛。

11、让设计指导而不是操纵开发：

敏捷建议在项目开始就编码，但并非不要设计，而是在开发的全过程中都有设计。

设计满足实现即可，不必过于详细。世界上没有代码工人，程序员不是打字员。

设计分战略设计和战术设计，战场瞬息万变，把事情交给程序员好了。

好的设计是正确的而不是精确的。//记住这句话！好的设计是因地制宜的，兵无常形水无常势。

12、合理的使用技术：

这个技术框架真的能满足需求吗？它的维护成本是多少？.....不要花时间开发你能下载到的东西，（拥抱开源？我的理解）

//不要过分设计，同时也不要过分玩弄技巧。

13、保持可以发布：

已提交的代码保持随时可以行动……任何时候，只要你没有准备好，那就是敌人进攻你的最佳时刻……

14、提早集成，频繁集成：

代码集成是主要的风险来源。敏捷是一个持续开发的过程，最好能在项目的早期实现集成，并且持续有规律的集成。

//坚持每天集成，每天都能看到效果，利国（领导满意）利民（自己满意）。

15、提早实现自动化布署：

测试人员也要像测试功能一样测试布署过程，可以借助自动化布署工具。但是使用自动化测试和布署，可以让持续集成更容易被接受，必可以让用户更早看到产品。

16、使用演示获得频繁反馈：

需求就象流动着的油墨，不可能被冻结。就象你不可能冻结市场、竞争和知识、成长。让开发的的过程对用户可见，双方都会觉得舒适。

//需求冻结？我的理解需求应该短时间被冻结，至少保证我们有一个冲刺时间，但长期不变，是不可能的。

17、使用短迭代，增量发布：

给我一个详细的长期计划，我给你一个注定完蛋的项目。//哈哈，太喜欢这个腔调了……

关注那些使产品可用且不可缺少的核心功能……尽快把软件交到用户手里。

18、固定的价格就意味着背叛承诺：

软件项目天生就是变化无常，不可重复，无法做出精确的评估，关于工期成本预算等等，都不可能精确估算……

让团队与客户在一起工作，由客户控制他们要的功能和预算。

第5章：敏捷反馈

一步行动，胜过千万砖家的意见！

19、守护天使『单元测试』：

代码在快速变化，你需要能持续获得代码健康状态的反馈，所以要编写能产生反馈的代码……

没有单元测试，就象高空作业没有系安全带一样。……

20、先用它再实现它：

编写代码之前，先写测试。站在代码用户的角度去思考，有助我们去设计一个更有用更一致的接口……

避免过度设计，好的设计并不意味需要更多的类……//简单就是好。

测试驱动(TDD)有助于为我们带来更简单更实效的的设计。//测试真的很重要，即能检查需求是否合理，又能检查设计和代码是否正确。

21、不同环境就有不同问题：

但是它在我的机器上就能正常工作。//程序员经常说的一句话，呵呵……

使用持续集成工具，在所有支持平台和环境下运行单元测试。

22、自动验收测试：

单元测试之外，关键业务逻辑要独立进行严格测试，并且最后需要用户审批。FlT（集成测试框架）可以帮助进行自动化验收测试。

23、度量真实的进度：

不要用进度百分比来度量进度，80％听上去不错，但它仍没有完成任务……//进度百比率就是PM给的一个自欺欺人的东西！

不要评估已完成的工作量占比，要测算还有多少工作量没有完成。评估那些需要完成的待办事项。如SCRUM中的每个Sprint。

24、倾听用户的声音：

任何问题都是开发团队的问题，不是用户的问题。//用户是上帝，怎么可能错？！……

大多数程序员总把问题归结到用户不会用，请耐心地倾听！每一个抱怨后都隐藏一个事实，找到真相，修复真正的问题……

如果代码解决不了问题，可以用文档和培训解决……

没有愚蠢的用户，只有愚蠢自大的程序员。//嗯，是的。

第6章：敏捷编码

任何一个笨蛋都能让事情变得越来越笨重，越来越复杂。

25、代码要清晰地表达意图：

代码清晰，设计简单，没有缺陷。PlE原则，意图清楚且表达明确地编程……

今天的你觉得显而易见的事情，对于其他人可能并不那么认为，对于一年以后的你也可能并不那么认为，所以，请保持代码的可读性吧………

26、用代码沟通：

程序员不要写太详细的WORD文档，不但有违TRY原则，也容易生成让人误解的文档……//错误的文档比没有文档更可怕

也不要依赖注释，只在关键的地方注释即可……注释不是告诉读者代码做了什么，而是要告诉读者为什么这么做……让代码遵循规范，简洁优美……

27、动态评估取舍：

过犹不及……没有适宜所有问题的最佳解决方案，每个设计都是解决特定的问题……让用户帮助你找到他们的痛点……

过早的优化是万恶之源。

28、增量式编程：

在很短的编辑／构建／测试的循环中编写代码，可以创建更加简洁清晰，易于维护的代码……更小的的方法和更具内聚性的类。

29、保持简单：

简单不是简陋……不要强迫自己陷入过度设计，也不要让代码过度复杂化……有节制地使用设计模式……

一个人以为简单的东西，也许对另一个人就觉得复杂。

30、编写内聚的代码：

让类的功能尽量集中，让组件尽量小……内聚性让代码更稳定……单一职责原则，重用发布等价原则。

31、告之，不要询问：

将命令和查询分离开……不要抢其它人的工作，告诉他们做什么，然后盯着自己的职责就好了（做人又何尝不是如此）……类似ObjectC的发送消息……

32、根据契约进行替换：

Liskov替换原则，派生类应该可以替换基类……对于is-a才使用继承，has-a 或uses-a 应该使用委托……

第7章：敏捷调试

真正的高手只是知道如何亡羊补牢。

33、记录问题解決日志：

不要在一个地方跌倒两次……记录你遇到的问题和你的详细的解决方案，以后你得到的帮助……

做一个 Wiki，让知识在团队成员中共享。//这个必须！！！

34、警告就是错误：

嗯，这个很好理解，只要条件许可，把所有警告都消掉吧……让编译结果就只有一个干干净净的Success，多完美！

35、对问题各个击破：

大型系统非常复杂，发生问题可能难以下手，如果有单元测试，有助于我们分离问题模块……如果没有，可以用原型系统来分离问题……

36、报告所有的异常：

即使不向用户展现，但自己人要可看见它们……不要擅自catch掉异常，除非你能处理它，否则就把它抛出去……

37、提供有用的错误信息：

给用户优雅的有建设性的错误提示，同时要在日志中提供详细的错误堆栈……

//多用日志解决问题，不要用System.out，太不优雅了！

第8章 敏捷协作

高效的协作是敏捷开发的基石。

38、定期安排会面时间：

立会（注意是立会，不是例会）……只要三个问题，昨天收获，今天计划和遇到的困难……

39、架构师必须写代码：

新系统的设计者要亲自投入到实现中……积极地编程带来深入的理解，优秀的设计从积极的程序员那里开始演化。

//太对了，不要招聘那些所谓的架构师！不写代码的架构师不是好架构师，不想当架构师的程序员不是好程序员。

40、实行代码的集体所有制：

让程序员轮换完成不同领域的不同模块的不同代码……有助于团队提升整体的知识和技能，提升代码的质量……

但是要保证每个领域有驻留专家……并且也不是意味每个人可以乱改代码。

41、成为指导者：

教学相长……//授人玫瑰手有余香……

分享自己的知识很有趣，付出的同时便有收获……

42、允许大家自己想办法：

接上一个习惯，授人以渔，而非授人以鱼……

43、准备好再共享代码：

决不提交尚未完成的代码，提交未通过编译或未通过单元测试的代码，在项目中是属于玩忽职守的行为……（Git这点做得挺好）。

//非常重要，乱提交代码，损人不利已。

44、做代码复查：

代码复查或许是找到问题并解决问题的最佳办法，比测试更有效……结对编程……所有人的代码都应该被复查……

代码审查的问题：代码是否易读？是否有明显错误？是否对其他模块有不利影响？是否重复？是否可以重构？

45、及时通报进度和问题：

发布进展和状况，新的想法，遇到的困难，不要等到领导来问你。//太对了，领导是一个很可怕的动物，千万不要招惹他。