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

敏捷(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个习惯笔记。