1、不要抱怨，把注意力集中到解决问题上来。
2、了解清楚情况，比如团队风格，业务需求等，才动手编码。
3、指出问题，当然，更好的做法是礼貌一点。
4、勇敢的说出实情，然后努力的去解决问题。
5、用邓公的话来说：与时俱进，开拓进取。
6、提倡团队成员之间的分享精神，比如搞个午餐会议（虽然听起来很蛋疼）。
7、抛弃旧习惯很难，这需要勇气，但是想要与时俱进，这是必须要做的，想想改革开放前后的对比。
8、对于一个问题，不满足于表象，不断追问'为什么'，当然，也要问到点子上。
9、把握开发的节奏，固定的时间做固定的事情，就像跳舞和演奏一样，一个节拍一动，充满韵味。（不只是开发，适用于一切工作。）
10、让需求方决定需求，而且描述越清楚越好，不然返修就是必然的。
11、设计和开发交替进行，不要被一开始的设计图牵着鼻子走。
12、根据需要选择技术，问自己为什么需要这种技术，其中一个标准是使用新技术是否无需时间成本。
13、使用版本管理工具，以免引入破坏性的修改导致系统死掉。
14、子系统频繁集成，有助于提早发现问题，以免后期隐藏的问题滚起雪球。
15、从一开始就使用自动化部署应用和环境，还是那个早期不做准备后期问题被滚雪球无限放大。
16、需求的变化是人的天性，如果不想在最后软件交付时才去面对用户的变化，那么就该使用演示获得频繁的反馈。
17、小步前进，使用短迭代、增量发布的方式开发大型系统，而且这也能避免跳票，还能根据用户的反馈及时修正方向。
18、固定的项目报价有悖于敏捷开发的原则，合理的做法是短迭代，由用户去评估每次迭代的成果并决定是否继续做下去。
19、使用自动化单元测试工具，每次构建和编译时都会运行之前留下的测试代码，能帮助发现新修改带来的错误。
20、测试驱动开发，即：在编写之前，先编写测试用例去使用它，出现问题是就马上针对问题去做开发。
21、使用持续集成工具，周期性的从源码控制系统中取得代码，并运行代码。这种方式能够帮助发现不同平台（操作系统）下的兼容问题。
22、使用FIT，即集成测试框架，使用户参与到验收测试的用例设计上来。
23、度量本次工作的时间花费，如果有错误，那么在下一次度量的时候就有了修改的依据。
24、倾听真实用户的声音，查看一下找出真正的问题所在。
25、代码要清晰地表达意图，比如说使用枚举来代替不明意义的数字，应该努力的增加代码的表现力。
26、保持良好的命名规范，使用代码来进行沟通，必要时加上注释，但是也请不要添加无意义的注释。
27、动态的评估各种因素：性能、成本、可移植性等，然后做出取舍，不要去追求不可达的“完美”。
28、编程如开车，不可能能一路踩着油门到达终点，使用增量编程的方式，分阶段去添加新的特性进来。
29、代码设计应该保持简单，在几百行代码中使用十几个设计模式是不可取的。
30、保持代码的高内聚，意味着一个模块内部所有函数都是为了齐心协力完成同一个功能，这呼应了第29条保持简单。
31、划分各自的职责范围，封装修改为命令，封装读取为查询，并设置一定的访问控制防止意外发生。
32、编程时需要更多的考虑程序语义，比如继承要求子类和父类是is-a的关系，如果不是is-a的关系可以考虑用聚合的方式做代码重用。
******33、可以把每日日报当做解决方案日志来做，碰到问题就把解决思路记录下来并做成可搜索的方式，这样再次碰到时就能亡羊补牢。**********
34、调高编译器的提示级别，把警告当做错误来处理，不要忽略它。
35、分离开模块做单元测试，对发现的问题做逐个击破。
36、抛出所有异常，除非你确实想好了怎么处理，不然与其让问题藏着掖着不如在发生的时候爆发出来留个全尸。
37、提供有用的错误信息给用户，比如说：[问题摘要][详细细节]。
38、提倡“每日立会”，并回答三个问题：1、昨天有什么收获？2、今天有什么计划？3、未来有什么障碍？
39、架构师必须写代码，原理阵线的将军难以成为合格的战役指挥者。
40、实行代码集体所有制，互相之间轮换维护各自的代码，这将提高代码的整体质量、易于维护、降低出错率。（极客与团队中也提倡代码不署名，方便他人作改动。）
41、与团队分享知识和经验，知识并不像金钱，给了别人自己就没有了，知识分享了之后就从一份变成了两份。
42、帮助他人可以不直接提供解决方法，而且告知如何去解决问题，相信别人也有这种能力，授人以鱼不如授人以渔。
43、向源码控制系统提交代码时，所有单元测试都是可以通过的，而且应该与一个特定的任务或是一个bug的解决相关，并注有日志信息。
44、在代码刚刚完成时，做代码复查能够很好的发现大部分BUG，复查的方式可以是轮换复查或者结对编程。内容可以是：1、可读性 2、明显的错误 3、对其他部分的影响 4、重复代码 5、可改进和重构
45、积极的通报进展和问题，不要等到时间截止的时候才来做这件事，也不要等别人来询问进展，积极主动才够敏捷。
