之前的文章写过 单元测试最佳实践 有兴趣的可以看一下，今天列出我的单元测试规范：

单元测试规范：

• 所有public方法必须被单元测试覆盖
• 只测试public方法
• 不要依赖其它的类，除非是静态Helper或者测试框架的类。
• 所有需要依赖类都必须被mock。
• 必须很快速的运行，单元测试里不能有耗时的代码
• 使用一些工具，比如NCrunch 可以在后台实时运行单元测试，随时知道自己写的代码有没有破坏测试。
• 文件，外部Service和数据库的存取都必须mock掉
• 单元测试要可以无限次的重复运行
• 单元测试不是要实验想法，不要去测.NET本身的问题。

CSS和JavaScript的规范网上有很多，今天列出一些规范

• JS代码一定要使用模块话，比如RequireJS, ES6等等
• 不能写内联样式
• 不要直接在页面写CSS和JavaScript代码 （放到独立文件里）
• 不要在JavaScript写HTML代码，除非是是组件里，尽量使用HTML Template
• BR 标签只用在段落里，不是用来换行的!!!
• CSS的命名需要和内容匹配，不要写成left-nav, 要是你想放到右边呢？使用side-nva.

就是这么几句，能做到就很不容易！

沟通是软件开发过程中极其重要的一部分，今天主要列一下做项目的时候沟通的规范

• 和客户沟通之前先和团队沟通。
• 第一时间提出你遇到的问题和障碍。
• 了解团队每个成员擅长的东西。
• 不要浪费时间寻找方案，如果团队成员有人有相关经验。
• 如果你自己对某些需求或者方案不确信的时候，一定要找团队一起沟通一下。
• 沟通的时候必须态度端正。
• 沟通的时候必须讨论事情本身，不得有人身攻击。
• 沟通的时候所有人都有表达想法的权利。
• 必要的时候 “Show me the code”!

给客户提交前除了完成之前提的Definition of Done, 良好的代码规范等，我根据大家比较容易忽略的地方，列出来作为这一方面的规范。

• 给客户列出按计划或者需求定义但是没有完成的功能 （这样，客户就不会把这类问题当Bug）
• 给客户准备测试数据
• 确保你的测试数据和你给的客户的版本匹配 （容易出错的就是数据库脚本和客户用的不一致）
• 列出客户需要注意的地方，比如数据库连接字符串，API地址等。
• 确保你的最后一次改动，程序能够工作 （容易出错的是你发现了一个错误，然后就改了，但是你觉得是小改动，没有测试，但是导致客户连主页都进不了）
• 确保客户测试或者运行系统需要的所有信息。

之前我讲过Git flow, 请参考我的文章敏捷实践系列(四)：代码管理流程

想知道个整体概念的，就看一下下面的图

我们团队的Git规范

• 使用Git时，总是使用SSH连接
• 任何时候不要在代码里包含密码，尤其是数据库密码，服务器密码，即使你删掉了，因为Git history可以看到所有历史！！！
• 严格遵守Git flow
• 每一次提交都要写清楚修改的是什么
• 每天离开办公室必须提交所有的代码到Git服务器
• 频繁提交 （small workable piece of code）
• 如果你feature分支没有完成,不要合并回Develop分支, 请参考之前文章 Definition of Done
• 仔细检查config的设置，不要用自己本地的覆盖了服务器上的。
• 每一个新的feature必须在一个新的分支上。
• 解决冲突后，一定要测试！！！

Definition of Done: 就是对做完一个功能的标准是什么，只有我们提前定义好了标准，我们才知道结果是一种什么样的期望。

我们团队的DONE标准

我们大家原来的时候总有一个习惯，你问进度如何，总是说快完了，马上完了，如果期望这个东西是10个小时做完，当天下班时，你问开发人员，他说的这个”马上”一定是至少还得一天，基本上他说90%了，那基本上就是还需要40%的时间来完成剩下10%的功能。
如果我们设置一个中间状态，那么事情永远到不了我们想要的质量，因为大家着急把功能做完，但是没有测，或者没有单元测试，或者还有一个小功能没有实现。

• 所有任务只有 “DONE” 和 “NOT DONE” 状态，没有90%完成这样的。
• 代码写完了，签入了，编译通过，符合当前版本的需求。
• 代码Review过了。
• 持续集成没有错误。
• 单元测试覆盖通过了。
• 部署到对应的环境并且测试通过了。
• 任何编译，部署和配置的改变都已经开发并且文档或者交流过了。
• 如果需要文档等都已写或者更新。

完整的DoD

细节就不解释了，如果需要解释的，请在文章后留言。

我一直认为一拿到任务就开始写代码是有问题的，而这是很多人的习惯，结果就是不断的修改，我还是那句话，作为程序员我们是要把代码写对，而不是把它改对。

下面我就说一下拿到任务后整个流程应该是什么:

1. 充分理解需求，不要立即写代码
2. 设计 （主要是思考如何实现）
3. 找出需要和别的代码交互或者集成的部分
4. 开始一个新分支
5. 设计接口 （尤其是需要和别人交互的代码）
6. 实现接口
7. 编译通过
8. 单元测试覆盖全代码
9. 所有单元测试通过
10. 冒烟测试通过，就是至少自己点一点，测一测
11. 功能测试通过
12. 合并Develop代码到这个分支
13. 若有冲突解决冲突.
14. 重复7到11.
15. 合并回Develop

下面是.NET项目的一些自己的规范

代码顺序

• Using clauses
• Name space
• Class
• Private field
• Protected field
• Private attribute
• Protected attribute field
• Public attribute field
• Constructor
• Public method
• Protected method
• Private method

代码注释

• 尽量不写注释
• 代码本身应该可以自解释
• 如果代码足够复杂，确实需要的时候再写注释
• 不要写只给自己看的注释，那叫笔记，你写到别的地方
• 如果代码没写完，就一定要加个 TODO: 注释

Hard-Code

• 永远不要hard-code
• 配置一定要放到配置文件，比如API地址，数据库连接，一些魔数等等

代码可读性上面

• 至少读三遍自己写的代码
• 团队里的人应该都能看懂你的代码，看不懂不能觉得别人笨，可能是自己代码可读性不高
• 不要出现水平滚动条 （1024以上的分辨率）
• IF语句签插一个空行
• Return语句钱插一个空行（除非return在if后面可以写到同一行）
• 方法之间要插入一个空行

异常

• 不要把异常堆栈信息抛到客户端
• 在程序最上层一定要不捕获未知异常
• 未知异常，日志里要记录堆栈信息
• 定义非常具体的异常，不要通过异常信息判断,
• 记录异常信息时使用 Log(ex.ToString()), 不要使用Log(ex.Message)

Password_Is_Less_Than_Seven_Exception Age_Must_Be_Greater_Than_18_Exception

NULL

• 不要忽略对NULL的处理
• 不要假设值永远不能空，如果是这样，请抛自己定义的异常
• 一些集合可以在构造函数里初始化，避免空
• 一些工具比如Resharper可以检查空

有不少写代码总是只按喜欢按自己的习惯写，但是如果这个产品永远是你自己一个人来写和维护，那么问题不大，那么如果是有很多人协作，那么麻烦就大了，我相信有很多人说了很多代码规范的重要性，我今天在这里只提两点意义。

可读性

代码规范最大的目的就是保持可读性。

Martin Fowler 说:

Any fool can write code that a computer can understand. 随便找个笨蛋都能写出电脑可以明白的代码

Good programmers write code that humans can understand. 好的程序员写的代码是让人能看明白的

其实，明白了可读性重要后，是有一些方法来提高可读性的。

1. 自己每写完一段代码，至少读三遍，看看是否能够明白，知道为什么要这么写和自己是怎么写的。
2. 代码写完了，可以让别人看你的代码，就看那一个方法，不要太多上下文，如果别人能够明白，就是很不错的。如果不明白，可能是命名不对，或者if,else太多大家被绕进去了。
3. 好的代码光看类名就知道类是做什么的，光看方法名就知道这一个方法解决哪一个具体问题（单一职责）
4. 写单元测试，如果代码测试覆盖率好，可读性也更好，前提是单元测试要写好。
5. 可读性好的代码，任何人也都可以帮忙写单元测试。

可维护行

代码规范的另一个主要目的就是可维护性。

可维护性就是：how easily a system can be modified

这个可维护性一定还是基于代码的可读性上，在可维护性方面有几个实践记得参考。

1. 写代码的时候一定要觉得我做的产品将来我会维护，当然肯定不全是，但是做的时候要这么思考
2. 保持一个廉耻心，心里想着如果代码不是我维护，将来千万不要改代码的时候让别人问候我的家人
3. 使用大家熟悉的技术或者通用的技术。
4. 使用大家常用的一些结构比如MVC, MVVM等等。
5. 使用一些好的实践比如单元测试 （修改代码的时候就不怕破坏隐藏的功能）
6. 留下必要的文档。
7. 项目相关的东西集中在一起。

我们团队做了好多年的项目，也成功提交了不少项目，所以我想总结一下一些好的实践，在这里给大家一个参考。

介绍

好的团队一定有一套自己的流程，不管是使用敏捷或者传统的开发过程，我相信都有一套自己的方法。我们团队实践多年的过程中，觉得敏捷是比较适合我们的，而在不断的摸索中对SCRUM更多的认可和适应了。今天我就先来简单的介绍一下SCRUM, 细节的内容大家请参考 <<硝烟中的SCRUM和XP>>

Scrum

下面的SCRUM东西，有很多是我们自己总结的。

SCRUM 主要流程

SCRUM 原则

• 关注产品的Delivery
• 透明
• 短迭代
• 整体质量
• 团队合作
• 持续沟通
• 承诺
• 自组织
• 尽早让问题暴露

团队组成

• 一般是5到9个人
• 开发团队全功能，开发，测试，UI等
• 全职
• 自组织
• 全体成员对质量负责
• 评估功能复杂度