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

标签：des   style   blog   http   ar   使用   sp   on   问题   

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

标签：des   style   blog   http   ar   使用   sp   on   问题   

原文地址：http://www.cnblogs.com/Michael282694/p/4158449.html