敏捷的编码

代码要清晰表达意图，项目是增量式开发，写程序也应该增量式编程。

代码要清晰地表达意图

要编写清晰地而不是讨巧的代码，向代码阅读者明确表明你的意图，可读性差的代码一点都不聪明（让自己或者团队任何人，可以读懂自己一年前写的代码，而且只读一遍就知道它的运行机制）

代码沟通

用注释沟通，使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码

动态评估取舍

动态评估权衡，考虑性能、便利性、生产力、成本和上市时间。如果性能够了，就应该把注意力放在其他因素上，不要为了感觉上的性能提升或者设计的优雅，从而将设计复杂化。

增量式编程

在很短的编辑/构建/测试循环中编写代码，这要比花费长时间仅仅做编写代码的工作好得多，可以创建更加清晰、简单、易于维护的代码。

保持简单

开发可以工作的、最简单的解决方案，除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。

当你觉得所编写的代码中没有一行多余的，并且仍能交付全部功能时，这种感觉就对了。这样的代码容易理解和改正。

编写内聚的代码

让类的功能尽量集中，让组件尽量小，要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。

告知，不要询问

不要抢别的对象或者组件的工作，告诉它做什么，然后盯着你自己的职责就好了。

根据契约进行替换

通过替换遵循接口契约的类，来添加并改进功能特性，要多使用委托而不是继承。

记录问题解决日志

对解决的问题可以记录以下条目：

问题发生日期

问题简述

解决方案详细描述

引用文章或者网址

任何代码片段，设置或对话框截图

警告就是错误

嵌入带有警告的代码，就跟嵌入有错误或者没有通过测试的代码一样，都是极差的做法。

对问题各个击破

在解决问题时，要将问题域和周边隔离开，特别是大型应用中

报告所有的异常

处理或向上传播所有的异常，不要讲他们压制不管，就算是临时这样做也不行，在写代码时要估计到会发生的问题。

提供有用的错误信息

提供更易于查找错误细节的方式，发生问题时，要展示出尽量多的支持细节，不过别人用户陷入其中。