“武功者，包括内功、外功、武术及技术之总和。有形的动作，如支撑格拒，姿势回环，变化万千，外部可见，授受较易，晨操夕练，不难熟练。而无形的内功指内部之灵惠素质，即识、胆、气、劲、神是也，此乃与学练者整个内在世界的学识水平密切相关，是先天之慧根悟性与后天智能的总成，总需寻得秘籍方可练成。”
——摘自《武林秘籍大全》
45个习惯
一、态度决定一切
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.及时通报问题与进展
告诉自己：
开发要持续不断，切勿时断时续；
不要孤立的写代码（Don't code in isolation!）；
你不需要很出色才能起步，但是你必须起步才能变很出色，即使你已经在正确的轨道上，但如果只是停滞不前，也仍然会被淘汰出局。——Will Rogers（美国著名演员）
不停地问为什么，不能只满足于别人告诉你的表面现象，要不停地提问直到你明白问题的根源。
鲨鱼必须不停地向前游，否则就会死亡。
计划是没有价值的，但是计划的过程是必不可少的。——艾森豪威尔
在设计过程中学习是有价值的。
不要开发你能下载到的东西（Don't build what you can download.）
不要开发那些你容易下载到的东西，虽然有时需要从做基础开发所有你需要的东西，但那时相当危险和昂贵的。
每一个抱怨的别后都隐藏了一个事实，找出真相，修复真正的问题。
不要单独的进行设计，特别是你自己。
好的设计应是正确的，不是精确的。
技巧了解与学习的资源:
敏捷工具箱
版本控制：
项目开发中所有的产物——全部的源代码、文档、图标、构建脚本等，都需要放入版本控制系统中，由版本控制系统来统一管理。令人惊讶的是，很多团队仍然喜欢吧这些文件放到一个网络上共享的设备上，但这是一种很不专业的做法。
如果需要一个安装和使用版本控制系统的详细说明，可以查阅《版本控制之道——使用CVS》或者《版本控制之道——使用Subversion》。
单元测试：
用代码来检查代码，这是开发者获得反馈的主要来源。
想要了解单元测试，可以看《单元测试之道Java版》和《单元测试之道C#版》，你可以在《JUnit Recipes中文版》一书中找到很多写单元测试的使用技巧。
自动构建：
不管是在自己的本地机器上实现构建，还是为整个团队实现构建，都是全自动化并课重复的。以为这些构建一直运行，所以又称为持续集成。
和单元测试一样，有大量的免费开源产品和商业产品为你提供支持。
《项目自动化之道》（JavaLamps使用，自动化地连接单元测试）介绍了所有自动构建的技巧和诀窍。
1.
用代码来测试变量的具体值（以及跟踪运行了多少个测试），已经是非常普遍的做法。你可以现在一个标准的测试框架，来帮助你完成简单的编写和组织测试的工作，如Java的JUnit、C#或.Net的NUnit，测试Web Service的Http Unit.
2. 单元测试只有在达到一定测试覆盖率的时候，才能真正地发挥作用。
测试覆盖率工具，大致了解自己的单元测试的覆盖情况。
3. 好的设计并不意味者需要更多的类。
4. TDD（Test Driven Development 测试驱动开发技术）
5. 持续集成（Continuous Intergration）
不同的环境，就有不同的为题。
使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等问题来找你。
一个持续集成系统，可以自动集成并报告集成结果。
持续集成系统就是在后台不停地检出、构建和测试代码的应用。可以自己使用脚本快速实现，也可以选择已有的免费开源的解决方案，它们提供更多功能且更稳定。】
6.FIT(集成测试框架）它可以更容易地使用Html表格定义测试用例，并比较测试结果数据
7.PIE原则（Program Intently and Expressively即意图清楚而且表达明确地编程)
代码必须明确说出你的意图，而且必须富有表达力，这样可以让代码更易于被别人阅读和理解。代码不让人迷惑，也就减少了发生潜在错误的坑能，一言以蔽之，代买应意图清晰，表达明确。
8.
《解析极限编程》
《重构：改善既有代码设计》
《计算机程序设计艺术》
9.记录问题解决日志
面对问题（并解决他们）是开发人员的一种生活方式。提高解决问题的效率，不妨维护一个保存曾遇到的问题以及对应解决方案的日志。
建议符合要求的格式：
a. 问题发生日期；
b.问题简述；
c.解决方案的详细描述；
d.引用文章或网址，以及提供更多细节或相关信息；
e.任何代码片段、设置或对话框的截屏，只要它们是解决方案的一部分，或者可以帮助更深入地理解相关细节。
要将日志保存为可供计算机搜索的格式，就可以进行关键字搜索以快速查找细节。
要共享日志给其他人，而不仅仅是靠一个人维护。把它放到共享的网络驱动器中，这样其他人也可以使用。或者创建一个Wiki，并鼓励其他开发人员使用和更新其内容。
平衡的艺术
a. 记录问题的时间不能超过在解决问题上花费的时间，要保持轻量级和简单，不必达到对外发布式的质量。
b.找到以前的解决方案非常关键。使用足够的关键字，可以帮助你需要的时候发现需要的条目。
c.如果通过Web搜素，发现没人曾经遇到同样的问题，也许搜索的方式有问题。
d.要记录发生问题时应用程序、应用框架或平台的特定版本。同样的为题在不同的平台或版本上可能表现得不同。
e.记录团队做出一个重要决策的原因，否则，咋6-9个悦之后，箱在重新回顾决策过程的时候，这些细节就很难咋记得了，很容易发生互相指责的情形。
·
10.RDoc（Ruby）、javadoc（Java）和ndoc工具可以方便地知己从代码注释创建有用的、格式优美的文档。
11.如果应用使用了中间层对象（比如一个COM组件）来访问数据库，数据库表结构变更所造成的影响就可以控制在一定的范围内，代码也更容易维护。
12.关键工作制图（UML）
461
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
