态度决定一切
1、做事
当出现问题，BUG的时候不要抱怨，指责，最终要的是解决问题。
2、欲速则不达
不要坠入快速的简单修复之中，要投入时间和精力理解它，并使代码保持整洁、敞亮。
不要孤立的编码，花时间阅读其他人的代码。
使用单元测试。
3、对事不对人
不要一味否定别人的意见，要提出自己的看法。
只有更好，没有最好。
不带任何情绪并不是盲目接受所有的观点。用合适的词和理由去解释为什么不赞同，并提出明确的问题。
4、排除万难，奋勇前进
如果发现项目中代码有问题，向其他成员反馈问题，并且想办法重写它。
学无止境
5、跟踪变化
迭代和增量式的学习：记录下想学的东西——当听到不熟悉的术语或短语时，简要的记录，然后有计划的深入学习。
了解最新行情：选择一些公认的优秀技术博客，了解顶尖博客作者们在关注什么。
参加本地的用户组活动。
参加研讨会议。
如饥似渴的阅读：好书，期刊杂志等。
6、对团队投资
提供你和团队更好的学习平台：可以搞一些类似午餐会议，提供一个团队分享的平台
不要局限于纯技术的主题
7、懂得丢弃
学习新的东西，丢弃旧的东西。
要果断丢弃旧习惯，一味遵循过时的旧习惯会危害你的职业生涯。
不是完全忘记旧的习惯，而是在使用适当的技术时才使用它。
对所使用的语言，要总结熟悉它的特性，并比较这些特性在新语言或新版本中有什么不同。
8、打破砂锅问到底
要不停地问为什么，直到明白事情的本质。
9、把握开发节奏
每天下班的时候提交所有的工作，包括测试代码。第二天开始新的内容。
每天固定时间固定地点的站立会议。
最大的节拍就是迭代时间，一般是1-4周。
项目开发需要一致和稳定的节奏。编辑，运行测试，代码复审，一致的迭代，然后发布。
交付用户想要的软件
10、让客户做决定
开发、经理、或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，由他们做决定。
不要用低级别或没有价值的问题打扰业务人员。
11、让设计指导而不是操纵开发
好的设计应该是正确的，而不是精确的。设计不应该涉及细节。
做一些类层次的设计：类名，职责，协作者。
白板，草图，便利贴是非常好的设计工具。
12、合理的使用技术
根据需要选择技术。
新技术就像新工具，它可以帮助你更好的工作，它自己不应该成为你的工作。
不要开发那些容易下载到的东西。
13、保持可以发布
提交代码之前: 在本地运行测试;检出最新的代码;提交代码
可以弄一个持续集成系统.
14、提早集成，频繁集成
决不要做大爆炸式的集成。
集成也不要太频繁，一天几次就差不多了。
15、提早实现自动化部署
系统安装、部署应该简单、可靠及可重复。
16、使用演示获得频繁反馈
需求就像是流动的油墨。
定期地，如一个迭代的结束，就与客户会晤，并演示你已经完成的功能特性。
维护项目术语表。
会晤也不要太频繁，只有在你做完一些东西可以给客户演示的时候 ，才进行。
17、使用迭代，增量发布
给我一份详细的长期计划，我就给你一个注定完蛋的项目。 （Show me a detail long-term plan, and I'll show you a project that's doomed.）
确定产品可用的核心功能，然后把它们放在生产环境中，越早交到用户的手里越好。
发布带有最小却可用功能块的产品，每个增量开发中，使用1-4周左右迭代时间。
18、固定的价格就意味着背叛承诺
构建系统最初、小的和有用的部分，之后再根据功能迭代，每个迭代给客户选择继续还是取消合同。每个迭代的费用还是相对可以评估的。并且客户承担更低的风险。
敏捷反馈
19、守护天使
编写能产生反馈的代码。-》自动化单元测试。
在后台架设一台构建机器，不断获得最新版本的源代码，然后编译代码，运行单元测试，有错误及时通知。
如果单元测试到位，可以随意重构代码。
简单属性的访问方法和价值不大的方法是不值得写单元测试的。
20、先用它再实现它
编程之前，先写测试。测试驱动开发
使你站在代码用户的角度。
有助于消除过度的设计。
好的设计并不意味着需要更多的类。
只有在具体理由的时候才开始编码，你可以专注于接口设计，而不会被很多实现的细节干扰。
测试优先和提交代码之前的测试要区分开来，测试先行帮助改进设计，提交代码之前还需要进行测试。
21、不同环境，就有不同问题
使用自动化在多个平台上运行测试。
22、自动验收测试
为核心的业务逻辑创建测试。让客户单独验证这些测试，要让他们像一般的测试一样可以自动运行。
23、度量真实的进度
专注于你的方向。
在真正完成一项任务时，要清楚知道完成这个任务真正花费的时间。
使用代办事项。
度量剩下的工作量。要评估那些需要完成的代办事项。
24、倾听用户的声音
没有给用户很友好的提示。
每一个抱怨的背后都隐藏了一个事实，需要努力找出背后真正的问题。
如果代码问题解决不了，可以用修改文档和培训来解决。
敏捷编码
25、代码要清晰的表达意图
开发代码时，应该更注重可读性，而不是只图自己方便。
代码必须说出意图，而且富有表达力。
26、用代码沟通
建立代码文档：利用代码本身；利用注释沟通代码之外的问题。
不需要注释来包裹你的代码。
使用细心挑选的名称和清晰的执行路径，代码几乎不需要注释。
对于类中的方法，可能要说明下面的信息： 目的；需求；承诺；异常。
解释代码做了什么的注释用处不那么大。注释要说明为什么这样写代码。
27、动态评估取舍
强调性能的重要性情有可原。但如果性能已经足够好了，就没有必要再花时间去投入了。
没有最佳解决方案。
过早的优化是万恶之源。
28、增量式编程
它可以精炼并结构化你的代码。
会使你倾向于创建更小的方法和更内聚性的类。
持续做一些细小而有用的事情，而不是做一段长时间的编程或重构。
在很短的编辑/构建/测试循环中编写代码。
要想重构代码一样重构你的测试，而且要经常重构测试。
29、保持简单
不要被迫过分设计，也不要将代码过分复杂化。
开发人员应该为自己创建一个简单并且可用的设计而骄傲。
简单不是简陋。
不要盲目使用模式、原则和高难度技术之类的东西。
当你觉得代码中没有一行是多余的，并且仍能交付全部的功能，这种感觉就对了。
30、编写内聚的代码
组件中各个类的功能类似，且功能紧密相关，这就是组件的内聚性。
类中的方法和属性共同完成了一个或一系列紧密相关的功能，这就是类的内聚性。
MVC模式分离展示逻辑、控制器和模型，它可以让开发人员获得更高的内聚性。
内聚性会影响一个组件的可重用性。
让类的功能尽量集中，让组件尽量小。