使用ReSharper打造团队代码

当前标签: 漂亮代码

 

请看高质量的代码——更新

Leo C.W 2014-04-01 19:16 阅读:544 评论:5

 

我们的终极编码规范

Leo C.W 2014-03-31 22:34 阅读:1275 评论:24

 

请看高质量的代码——查询

Leo C.W 2014-03-31 10:41 阅读:1037 评论:15

 

论C#之多继承

Leo C.W 2014-01-07 22:50 阅读:2319 评论:40

 

如何写出漂亮的代码——巧妙的接口扩展

Leo C.W 2013-05-09 23:00 阅读:322 评论:8

 

如何写出漂亮的代码——不应有的返回值

Leo C.W 2013-04-08 21:32 阅读:355 评论:5

 

如何写出漂亮的代码——臃肿的service

Leo C.W 2013-03-27 23:25 阅读:648 评论:9

我们的终极编码规范

Leo C.W 2014-03-31 22:34 阅读:1275 评论:24

 

如何控制项目进度和质量

Leo C.W 2014-03-28 23:27 阅读:517 评论:5

 

使用ReSharper打造团队代码检查流程

Leo C.W 2013-07-15 12:33 阅读:435 评论:1

使用ReSharper打造团队代码检查流程

 

首先我想跟大家分享一下我们团队的代码检查流程。

1. 项目经理随时会检查成员的代码，如果发现有不符合规范的代码，会在注释里面加todo。比如，假设leo的代码不符合规范，那么项目经理就会加注释：

//todoleo: refactor below code to match the standard of defining a class in JS

2. 每个成员随时会检查属于自己的todo项，然后修改代码。比如，leo会把项目里所有todoleo的项列出来，然后一个一个检查。检查完了之后，将todo改成review。

3. 项目经理会检查所有的review。如果代码没有问题了，就会删除这个review（曾经的todo）；如果代码仍然有问题，那么会再次改成todo。

 

下面我再一步一步详细介绍如何使用resharper来实现这一个流程。

1. 下载、安装、破解resharper。下载地址：http://www.jetbrains.com/resharper/。下载之后直接安装，安装后再百度下keygen吧，如果找不到，可以联系我。

2. 为每一个团队成员指定唯一的名字，通常为成员名字或者姓的拼音，只要简单易记就可以了。比如todoleo, tododaniel, todoben. 再将这些名字告诉每一个成员。

3. 打开VS， 在菜单栏找到Resharper，然后打开todo items。（此时你必须要打开一个项目才看得见）

 4. 点击settings（如下图），这是会打开resharper对于todo item的设置。当然，你也可以通过菜单栏resharper-options-tools-todo items打开该设置。

5. 你可以选中一个pattern，再点击duplicate，然后后再在编辑表单中修改。你也可以基于下图的设置来修改，注意红框框标记的地方。

6. 设置好了之后点击resharper - options的保存，退出设置。此时再打开todo-items，你可以看到filter下方有你自定义的过滤条件了。这些pattern会像resharper自带的todo，bug一样，在注释中加粗显示，特别醒目。

好了，上面就是全部的操作，非常简单吧。

 我们团队已经使用这一代码检查流程有几个月了，在实践中发现这一流程非常有用，让每一个成员的工作变得独立，同时又能得到项目经理对代码质量的控制。

 

我们的终极编码规范

 

我们的终极编码规范，最重要的只有3点：

1. 每一个文件不能超过300行代码，最好不超过200行；
2. 每一个方法不能超过30行代码；
3. 不写一行注释。

这3点看上去很简单，但是很多人做不到，即使是多年工作经验的。我们提出这3点，有很多人不相信做得到，或者认为即使做到实际意义也不大。事实是，我们多个项目成功做到了这3点，我们的团队深刻体会到了写代码的优雅、写代码的艺术。

 

这3点应该在所有项目中遵守，不管是c#，还是js、HTML、java，都应该尽可能达到。

 

除了这3点，还有其他几点可供参考：

1. 每一个文件夹不能超过30个文件和子文件夹，对于架构而言；
2. 业务相关的代码一定要放到一起；
3. 尽可能降低各个类的耦合度；
4. 写任何代码，当性能不是问题的时候，都应该把代码写的更易读。

 

命名指导：

 

对于日期和时间的命名。如果存的值只是日期，那么以Date结尾；如果值是时间，那么以Time结尾。如：CreatedDate代表这条记录的创建日期，不包含时间；CreatedTime代表这条记录的创建时间，包含日期和时间。

 

命名要准确，不可模糊。不能因为命名太长而选择有歧义或模糊意义的命名。比如以前项目中的一个案例：数据库中有一个“Recipe（菜）”表，做这个菜的时间包含：PrepareTime, CookTime, OvenTime, CleanTime。这里的命名有问题，因为调用者不知道这里Time是存的秒还是分还是带小数的小时，于是改成：PrepareMinutes, CookMinutes, OvenMinutes, CleanMinutes。另一个常见例子是，单词“interval”用作命名的时候，调用者也不清楚是分钟还是毫秒，于是后面都要加单位。

 

Bool类型返回值的方法，除了is做前缀外，还有can, will, does, has, should。以前在项目中看到一个方法，叫IsReceiveMessage，我在想是不是IsReceivingMessage，因为很多国内程序员英语语法不好，但后面我看到注释才发现，这个方法实际上是判断用户是否能收到短信，也就是说这个方法应该叫CanReceiveMessage。我相信写这个方法的程序员，写完这个方法命名时，肯定自己读着也感觉不太懂，所以加了个注释。实际上所有加注释的地方，要么命名不准确，要么方法太长。一旦你发现自己在写注释，那么你就需要思考这2个问题了。

 

未完待续，本帖长期更新中...

 

 

标签:  项目管理,  代码检查,  resharper