O**o
发帖数: 2071 | 1 我觉得我需要一个code review process。但是不知道要怎么弄。我曾经有个
consultant, 他给过我一些coding standard and code review check points.
这个coding standard有个二十来页，无非是些naming convention, comments,
javadoc这些个东西，跟当年java.sun.com，现在oracle网站上面的没什么大区别，排
版好看一些而已。
然后这个code review check list, 共80项，号称每个module/web page都要查这80项
。靠，这怎么搞啊？这不是坑姐吗？80项每一项都够查一阵子的。这玩意工作量很大啊
，我觉着比coding工作量还大啊。谁有这么多闲功夫一条一条琢磨啊？我不可能一个
developer写出code陪俩Sr. developers做code review啊。
难道就是走个过场？那负责code review的同志不是很惨？sign off之后那就是责任啊
。再说我确实code有点乱，确实想搞这么个process，不是想走过场的。除了general
coding standard, 还有security standard，跟那个什么OWASP有关。
请问各位牛人，你们公司里都是怎么弄这个的？要预留出多少时间给code review呢？
code review如果发现有问题又怎么处理？
感谢感谢！
===================
附：
从80条里面随手paste几个：
All the variables (member variables, local variables) are initialized. (
Either to some object or null or 0)
Judge whether String.length() / String.getBytes().length() should be used.
Unnecessary imports are not present.
Check whether it is not a double loop. | T******T
发帖数: 3066 | 2 During my brief SW years, we followed a multi-tier code review process in
order to achieve the so called CMM-level II certification.
1) Each developer follows the "PSP (personal software process) " (pushed by
CMU's Software Engineering Institute). The process involves daily line by
line self code review, line of code tracking, defect tracking, task/schedule
tracking. Each developer's database then gets summarized and tracked at the
team's level. This process is meant to track a developer's code quality
progression as he/she adopts PSP as a day-to-day task. The database tools
we used to implement PSP was developed in-house, java-based.
2) Peer code review, each developer's design is assigned two peers to review.
The designer is responsible for presenting the design document for the
modules/functions under review as well as presenting the general logic/
algorithms behind the design. The peer reviewers then proceed through the code line by line, function by function looking for functional, logical issues,
but not syntactical errors. The idea is not to shift responsibility for the
sign-off, but to really leverage those 2nd/3rd pairs of eyes. These reviews
should be done in hours, not days.
3) Module level Interface review, this is conducted at the team level,
where blackboxes are meant to interface with one other. Only the interfaces
and design intentions are reviewed to iron out any mis-communications
between the module owners. If there are any multi-threaded/multi-process
limitations/requirements, this could be the review meeting to discuss that
as well.
I think 80 categories is probably an over-kill, I would suggest cutting it
down to 10-20 essential ones, but definitely do the 1-2 person peer review.
It helps quite a bit just to have the designer revisit his own logic as he
explains it to the reviewers.
In my experience, self code-review will root out most of the bugs fast, but
it has to be somehow enforced or tracked or people just won't do it.
Following PSP to the dot was a pain in the neck, I hated it and it was a
real time hog, so it'll be up to you to strike a balance.
【在 O**o 的大作中提到】
: 我觉得我需要一个code review process。但是不知道要怎么弄。我曾经有个
: consultant, 他给过我一些coding standard and code review check points.
: 这个coding standard有个二十来页，无非是些naming convention, comments,
: javadoc这些个东西，跟当年java.sun.com，现在oracle网站上面的没什么大区别，排
: 版好看一些而已。
: 然后这个code review check list, 共80项，号称每个module/web page都要查这80项
: 。靠，这怎么搞啊？这不是坑姐吗？80项每一项都够查一阵子的。这玩意工作量很大啊
: ，我觉着比coding工作量还大啊。谁有这么多闲功夫一条一条琢磨啊？我不可能一个
: developer写出code陪俩Sr. developers做code review啊。
: 难道就是走个过场？那负责code review的同志不是很惨？sign off之后那就是责任啊
| f**********o
发帖数: 793 | 3 1. 首先让每个developer用 code analysis tools 来分析code.
确保符合规范。
象.net 有free 的stylecop和fxcop. 或者 Resharper.
Java 因该也有很多。
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_anal
2. 然后让每个developer做unit test.
保证code coverage over 80%
3. 最后还得人看，但会省力很多, 比较符合agile的风格. | O**o
发帖数: 2071 | 4 万分感谢，万分感谢。//鞠躬
by
schedule
the
tools
review.
【在 T******T 的大作中提到】
: During my brief SW years, we followed a multi-tier code review process in
: order to achieve the so called CMM-level II certification.
: 1) Each developer follows the "PSP (personal software process) " (pushed by
: CMU's Software Engineering Institute). The process involves daily line by
: line self code review, line of code tracking, defect tracking, task/schedule
: tracking. Each developer's database then gets summarized and tracked at the
: team's level. This process is meant to track a developer's code quality
: progression as he/she adopts PSP as a day-to-day task. The database tools
: we used to implement PSP was developed in-house, java-based.
: 2) Peer code review, each developer's design is assigned two peers to review.
| b*******3
发帖数: 1461 | 5 I had to do this. lol
【在 O**o 的大作中提到】
: 我觉得我需要一个code review process。但是不知道要怎么弄。我曾经有个
: consultant, 他给过我一些coding standard and code review check points.
: 这个coding standard有个二十来页，无非是些naming convention, comments,
: javadoc这些个东西，跟当年java.sun.com，现在oracle网站上面的没什么大区别，排
: 版好看一些而已。
: 然后这个code review check list, 共80项，号称每个module/web page都要查这80项
: 。靠，这怎么搞啊？这不是坑姐吗？80项每一项都够查一阵子的。这玩意工作量很大啊
: ，我觉着比coding工作量还大啊。谁有这么多闲功夫一条一条琢磨啊？我不可能一个
: developer写出code陪俩Sr. developers做code review啊。
: 难道就是走个过场？那负责code review的同志不是很惨？sign off之后那就是责任啊
| b******o
发帖数: 245 | 6 haha
【在 b*******3 的大作中提到】
: I had to do this. lol
| l***a
发帖数: 2677 | 7 lol
【在 b*******3 的大作中提到】
: I had to do this. lol
|
|
