敏捷(agility)

1 态度决定一切

1.1 做事

- 先解决问题，再追究责任

1.2 欲速则不达

代码除了可以运行外，还要保持整洁不要为了追赶工期而陷入简单修复的陷阱（+1/-1修复）第三方代码除了可用外，还要知道其大体原理要进行代码复核，保证代码质量，增加知识

1.3 对事不对人

表达观点，懂得沟通技巧容纳自己不能接受的想法设定deadline，确保执行力设定仲裁者，防止决策被资深员工控制，及时制止假大空话支持已经做出的决定

1.4 排除万难，奋勇前进

发现问题，不要试图掩盖，要敢于担当要诚实，要有勇气说出实情

2 学无止境

2.1 跟踪变化

**无需精通所有技术，但要知道行业动向**迭代和增量式学习，每天有固定的学习时间了解最新行情参加技术活动、各种研讨会等

2.2 对团队投资

构建学习型团队，做到知识共享午餐会议每周一次的主题会议（技术和非技术）

2.3 懂得丢弃

适时地丢弃旧技术丢弃旧思维方式方法

2.4 打破沙锅问到底

追根溯源，有目的的问一系列的为什么从“这个，我不知道”切入，开始调查

2.5 把握开发节奏

迭代周期一般在1~4周在一个迭代周期内，尽量避免需求变更每日提交可运行的代码减少加班，加班意味着计划失败，节奏打乱

3 交付用户想要的软件

3.1 让客户做决定

决定什么不该决定准备几种备选方案，从业务角度把优缺点、潜在成本和利益介绍给客户

3.2 让设计指导而不是操纵开发

设计会随时变动设计满足实现，不必过于详细，拒绝front big design**方法论：CRC卡(类-职责[这个类能做什么]-协作[需要哪些类一起工作])**设计是正确的，不是精确的设计是战略而非战术

3.3 合理使用技术

新技术能解决问题吗会被新技术拴住吗成本（学习，维护）高吗不要开发能下载到的东西，比如orm框架新技术是工具，不是目的

3.4 保持代码随时可以发布

3.5 提早集成，频繁集成

尽早集成，降低风险频繁集成，每日集成5~10次（大项目）

3.6 提早实现自动化部署

3.7 使用演示获得频繁反馈

频繁的向客户演示，频繁的得到反馈

3.8 短迭代，增量发布

3.9 固定的价格就意味着背叛承诺

学会评估每一个迭代周期做评估

4 敏捷反馈

4.1 守护天使

测试：编写能反馈的代码

4.2 先用再实现

TDD：测试驱动

4.3 不同环境，有不同问题

持续在多平台集成使用自动化集成

4.4 自动验收测试

4.5 度量真是进度

通过以往的经验，校正评估一直保证下一步工作是可见的**方法论：列出待办事项**

4.6 倾听用户的声音

每一个抱怨背后都隐藏了一个事实没有愚蠢的用户，只有自大的开发人员

5 敏捷编码

5.1 代码要清晰的表达意图

**PIE原则：programm intently and expressively**提高可读性，要优于讨巧的代码代码被读的次数要远高于被编写的次数

5.2 用代码沟通

良好且适度的注释**良好的注释包括： 目的：为什么需要这个类？ 需求（前置条件）：方法需要什么样的输入？对象必须处于何种状态？ 承诺（后置条件）：执行后，对象处于什么状态？有哪些返回值？ 异常：可能发生什么样的问题？会抛出什么异常？****方法内部由清晰的代码来解释，无需繁杂的注释**优雅清晰可读的代码要优于注释的解释注释不能替代良好的代码

5.3 动态评估取舍

项目要有侧重点：性能、生产力、优雅、成本、deadline由客户聚顶项目的侧重点过早优化是万恶之源

5.4 增量式编程

经常留心可以改进的微小方面

5.5 保持简单

不易程序的复杂性为荣简单不简陋

5.6 编写内聚的代码

内聚，单一职责细分要适度，不然会成一盘散沙

5.7 告知，不询问

守住自己类或模块的职责，把命令告诉其他类或模块，不关心实现

5.8 关于继承

is-a：使用继承has-a/uses-a：使用委托相对于继承，委托更灵活

6 敏捷调试

6.1 记录问题解决日志。

**方法论： daylog：每日日志 问题发生时间。 问题简述。 解决方法。 引用文章或方法。 辅以代码片段或截屏。**

6.2 警告即错误

6.3 对问题各个击破

无需查看所有代码强化单元测试

6.4 报告所有异常

设计工作决定有谁来负责处理异常报告有实际意义的异常解决所有的异常，处理或向上抛出，但不要捕获了不处理

7 敏捷协作

7.1 会议

“立”会**方法论：站立会议：10-15min 昨天有什么收获？ 今天计划要做哪些工作？ 面临哪些障碍？**scrum法则：猪（开发、产品所有者、协调者）、鸡（管理，支持，QA）**猪发言回答以上三个问题，不能展开深入讨论（会后单独讨论） 鸡记录问题，引导会议，但不能跑出上面的三个问题**

7.2 架构师必须编码

不要做“ppt架构师”，架构师必须编码鼓励编程人员参与到好架构设计中来

7.3 代码共有

要让开发人员轮换完成系统不同领域的不同模块的不同任务要珍惜团队的主流专家，但并不意味着其他代码对他封闭代码共有并不意味着泛滥地修改别人的代码，到处破坏向整个团队分享知识，降低风险

7.4 成为指导者

指导不是领导做到知识分享，授之以渔分享的范围不必拘泥于自己的团队，甚至是整个行业

7.5 允许大家有自己的想法

授之以渔

7.6 准备好后再共享代码

嵌入的代码必须可运行没有做完的代码可以通过其他方法异地继续**远程访问 u盘拷贝 版本库分支 ……**

7.7 代码复查

检查方法**集中复查：集中某一个时间段大家一起复查其他成员的代码****捡拾复查：准备迁入前，由另一个人接管代码进行复查****结对编程：俩人一起写代码**检查内容**检查能否被读懂和理解？ 代码是否有明显错误？ 是否对其他部分产生影响？ 是否有重复代码？ 是否存在需要改进和重构的地方？ ……**优势**提升代码质量 降低错误率 知识传播 降低由于人员变故带来的风险**

7.8 及时通报进展与问题

主动向上级汇报进度情况及原因，使问题及时解决，以及自己不会陷入被动要知道你所汇报的对象关注点在哪里


见：高效程序员的45个习惯笔记

『阿里巴巴内部分享』高效程序员的45个习惯笔记