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

最近看了《高效程序员的45个习惯：敏捷开发修炼之道》，笔记整理如下，备用。

这些习惯应该是一些好的习惯，可以试着尝试，而不是生搬硬套。加粗显示一些我能理解的注意内容。

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1做事放在第一位，不是指责犯错误的人。不抱怨，承认错误，团队合作，学习进步。懂得丢弃，
2欲速则不达，不能孤立，代码审核，单元测试，
3持续学习，跟踪变化，增量学习，了解动向，建设学习型团队，小步进步持续才是敏捷，丢弃原有知识和存量，用建议的开发环境开发一门语言的项目，多问为什么且问在点子上，问前问自己；有计划不随意，有节奏的码代码，一天几个时间段的提交，不要让天打断在进行中的事情。有节奏的开会，提前暴露问题，且像游戏一样一点点的成功激励。
4客户做决定，设计指导而不操纵开发，提早和频繁的集成代码，保持可发布。自动化部署，频繁演示反馈，增量部署，设计不要太详细，
CRC类，职责，协作，——要用简单的工具尽快做类关系图的设计。

技术引入：为解决什么问题，可取消性，成本。
能下载的不开发，除非你明确一个目标。
技术是工具而不是工作。

保持可发布：数据库，接口等提供多版本控制，实在不行就做分枝。

自动化部署，简单可靠的可重复。检查环境依赖，不能随意删除原有用户配置，带卸载，

演示和反馈的周期一周到两周，但也要尊重客户时间。让客户感觉到他们能在一定程度上控制项目的方向。演示的目的是反馈，不是故意暴露项目的缺陷

迭代是短期迅速的，用户更希望现在有一个能工作的不完美软件，而不是一年后的完美软件。短迭代带来专注和效率。

估价，短迭代，第一个周期后报价，此时你把握难易，客户可控方向。

5，敏捷反馈 编写能产生反馈的代码，自动化单元测试，每次编译运行测试，测试不通过，等同编译不通过，测试可重复，测试边界。
TDD测试驱动开发，先用再实现，以使用者角度开发，考虑怎么用，注重实效。有具体理由再编码，专注于接口。
成功的实现特定功能的最低版本。
构建一个持续集成的自动化部署系统，代码每次提交都自动部署测试，这样立即就会发邮件通知提交者是否通过。
自动验收测试，平面化的数据文件，
度量剩下的工作量，用时间做单位。
倾听用户，分析他们的问题，改系统。

6敏捷编码，代码尽量简洁，自说明，清晰不讨巧，代码被阅读次数远高于编写修改次数。
DRY原则，不重复自己，
注释，说明方法行为 意图 期待结果 要注意的地方。
类的方法的注释：目的（为啥需要），需求（前置条件，要输入和当时对象状态），承诺（输出和对象状态），异常。
重写方法时要保留原有的意图和约束。

动态评估取舍： 性能，便利，成本，上市时间，平衡考虑，没有最优方案

增量的开发，更产生小方法和内聚的类，持续测试开发。简单代码简单设计，以简洁为荣。以内聚为荣，功能职责单一，可修改的因素单一，
告知，不询问： 命令与查询相分离模式，内聚。封装 钱包的故事。
告诉对象或组件你要做什么，然后等待他给你结果。消息传递概念，而不是调用函数。查询绝不能改状态。
根据契约替换 ： 子类集成自父类的方法，不应改变其意图（不要求更多，不承诺更少）。 子类方法的异常抛出也应可替换。
is a使用继承，has a和 uses a 使用委托。 使用继承时考虑能否替换，不能则该使用聚合，类中包括一个其他类的实例对象，将责任（工作）委托给该对象完成。并且以后可方便替换该对象，因为它对外不可见，灵活扩展。

7 敏捷调试 记录问题解决日志：开发日志，可以包括 时间，问题描述，解决描述，代码片段，截图，辅助网址等。轻量简单的记录。 记录重大决策的原因，避免相互推卸责任。

警告 就是错误，一个变量未使用时可能是其他变量被错误使用了。警告是定时炸弹，让代码不可预测，质量下降。可修改编译器报警级别，把警告作为错误提示，有全局设置。 也应平衡时间，不行就先记录警告留待处理。
放弃的方法不再使用，系统或自己的。添加放弃提示和应对提示，表明放弃版本和时间。

对问题各个击破：使用mock模拟对象，对单元测试过的代码隔离。用原型还原问题请专家，原型隔离帮分析。二分查找，分析服务运行日志。

报告所有异常

8 敏捷协作
立会 每天进行，昨天收获，今天计划，会有什么问题，到公司一小时后进行，每人俩分钟。不深入讨论（可会后单独深入），猪参与鸡不，预约1小时会议室，进行15-30分钟合适。小团队2天一次或一周2次。团队意识

架构师码代码，移除软件不可逆部分，去除所谓架构概念。实际情况设计。

代码公有，任务轮换，让大家接触不同部分的代码，接触彼此的代码。但并不是随意修改，必须的注释，必要的修改。平衡，有些专家领域的只开放浏览学习。

成为指导者 共享知识，团队提升，知识、经验、体会，开博客等分享而不是讲座，可以结对编程。让别人相信你可以帮他们，而不是故意订立规矩为难他们。

允许大家自己想办法 告诉别人思路，让他们自己思考和实现，一段时间后反馈，看是自己的起作用，还是他们的新方式，能让自己学习。

准备好后再共享代码 完成一项任务后，立即提交，可备别人使用并收集反馈。原子提交并加注释，便于回滚。

代码复查：查找问题效率高，但可能会牺牲一些时间，并引发一些反感。-互相复查是一种方式，或者结对编程。 要订制检查问题列表，包括不限于 所有异常处理不空，代码易于理解，是否有明显错误，是否解耦不影响其他模块，是否重复，是否可重构等。代码复查不是批评，应允许不同的实现方式。

及时通报进展和问题 别等到最后一刻才报告问题，立会时。

9走向敏捷
开发习惯一点点引入，困境的项目如果一下改变必然失败，像不能要求一个病人立即运动一样。
引入敏捷 目的是为了更轻松的工作，
步骤： 1让团队知道接下来要发生什么，从立会开始，让架构师(所有人)参与编码，开展非正式代码审核。
2准备开发环境，版本控制、单元测试、自动构建、日志记录、开发日志。
3带团队进入固定节奏，用5、6、7章的习惯解决日常问题。

另外，可以-面向下级写周报，自己有习惯，逐步影响身边人。

over. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~