“接纳别人的想法，而不是盲目接受，这是受过教育的头脑的标志。”
— 亚里士多德
态度篇:
1、做实事
少抱怨和牢骚，少指责他人；找出问题所在，想办法解决；用于承担责任
2、欲速则不达
权宜之计不能长久；代码质量至关重要（持续重构）
3、对事不对人
就事论事
4、排除万难，奋勇前进
勇气是克服困难的唯一方法
学习篇
5、跟踪变化
新技术层出不穷，坚持学习；参与技术活动，多与人交流；把握技术大趋势
6、对团队投资
打造学习型团队
7、懂得丢弃
老套路和技术，该丢则丢
8、打破沙锅问到底
多问为什么
9、把握开发节奏
控制好时间，养成好习惯，尽量不要加班
开发流程篇
10、让客户做决定
用户必须在现场，倾听他们的声音，对业务最重要的决策他们说了算
11、让设计指导而不是操纵开发
设计是前进的地图，指引的是方向，而不是目的本身。设计的详略程度应该适当
12、合理地使用技术
根据需要而不是其他因素选择技术。对各种可选技术方案进行严格筛选，真诚面对各种问题
13、让应用随时都可以发布
通过持续集成和版本管理，随时可以编译、运行甚至部署应用
14、提早集成，频繁集成
集成有风险，要尽早尽量多地集成
15、提早实现自动化部署
16、使用演示获得频繁反馈
17、使用短迭代，增量发布
18、固定价格就意味着背叛
估算应该基于实际的工作而变化
工具篇
19、守护天使
自动化测试是你的守护天使
20、先用它再实现它
测试驱动开发
21、不同环境，就有不同问题
要重视多平台（跨平台）问题
22、自动验收测试
23、度量真实的进度
在工作量估算上，不要自欺欺人
24、倾听用户的声音
每一声抱怨都隐藏着宝贵的真理
编程篇
25、代码要清晰地表达意图
代码是给人读的，不要耍小聪明
26、用代码沟通
注释的艺术
27、动态地进行取舍
没有最佳解决方案，各种目标不可能做到面面俱到，关注对用户重要的需求
28、增量式编程
写一点代码就构建、测试、重构、休息。让代码干净利落
29、尽量简单
宁简勿繁。复杂必须有充足的理由。
30、编写内聚的代码
类和组件应该足够小，任务单一
31、告知，不要询问
多用消息传递，少用函数调用
32、根据契约进行替换
委托往往优于继承
调试篇
33、记录问题解决日志
不要再同一地方摔倒两次。错误时最宝贵的财富。
错误归档记录信息应该包括：
. 问题发生日期
. 问题简述
. 解决方案详述
. 引用文章或网址，以提供更多细节或相关信息
. 任何代码片段、设置或对话框的截屏
34、警告就是错误
忽视编译器的警告可能铸成大错
35、对问题各个击破
分而治之
36、报告所有的异常
37、提供有用的错误信息
稍微多花点心思编写错误信息
团队协作篇
38、定期安排会面时间
常开会，开短会（站立式会议）
39、架构师必须写代码
不写代码的架构师不是好架构师。好的架构师来自实际编程，编程可以深入的理解代码
40、实行代码集体所有制
让开发人员在系统不同区域中不同的模块和任务之间轮岗
41、成为指导者
教学相长。分享
42、让大家自己想办法
指引方向，而不是直接提解决方案
43、准备好后再共享代码
不要提交无法编译或者没有通过单元测试的代码
44、做代码复查
复查对提高代码质量、减少错误极为重要
45、及时通报进展与问题
另外，猪和鸡的比喻蛮有趣的！
代码复查checklist:
所有异常处理程序不允许为空
输入参数是否检测了有效性
代码可读性
是否有明显错误
是否存在重复代码
....