态度决定一切
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模式分离展示逻辑、控制器和模型，它可以让开发人员获得更高的内聚性。
内聚性会影响一个组件的可重用性。
让类的功能尽量集中，让组件尽量小。