一、是否需要代码规范
现代软件发展中，一个软件大多都是由一个团队来完成，在团队合作过程中，工程师们做最多的事情就是“看别人的代码”，如果每个人的代码风格迥异，没有统一的规范，旁观者看的时候非常头痛，看都看不懂何谈开发和维护。而统一的风格使得代码可读性大大提高了，规范的代码在团队的合作开发中是非常有益而且必要的。
针对题目中的四个论点的反驳：
-
这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
开发软件是一个团队活动，而不是个人的英雄主义。也许规范对个人的开发效率会有负面影响，但是对于团队合作来说，编码规范使成员之间可以轻松地阅读对方的代码，这恰恰能够节约大家的编程时间提高工作效率,使开发人员集中精力关注他们真正应该关注的问题，完善他们的软件，开发出更有价值的软件。而且软件开发人员流动性大，编码规范使新的开发人员能够很快的接手项目组其他成员的工作，快速完成工作交接。
-
我是个艺术家，手艺人，我有自己的规范和原则。
就像书中所说：软件都是在相互合作中完成的。合作的最小单位是两个人，两个工程师做的最多的事情就是“看代码”。如果在团队中遵从个人英雄主义，这样会影响到整个团队的工作。我在网上查阅时看到过这样的一句话“任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优先的程序员。”
-
规范不能强求一律，应该允许很多例外。
我认为规范之所以称之为规范就具有强求性。当然规范也是要不断地修订，但是规范一旦发布就应该保持一致。即使有例外，也只能是少数情况，而不能是很多例外。如果每个人都有例外，这些例外堆积起来规范就不复存在，每个人又被“个人主义”所主导。
-
我擅长制定编码规范，你们听我的就好了。
规范的产生应该是民主的决定，而并非一人主导。每个人都有自己的编码风格，如果每人都提出用自己的风格来制定规范也不复存在。如果对规范有意见，可以通过一定方法修订并发布新的规范，但是在新的规范发布之前，请遵守统一的规范。
二、代码复审
这次我复审的代码是我的结对伙伴钟灵毓秀的代码。博客链接：http://www.cnblogs.com/zlyx/p/5272805.html 代码如下：
#include"stdio.h" #include"stdlib.h" #include<time.h> main(){ int a,b,result,i,j,m,n; printf("四则运算题目数量："); scanf("%d",&i); srand( (unsigned)time( NULL ) ); for( j = 0; j < i;j++ ) { a=rand()%100+1; b=rand()%100+1; m=rand()%100+1; n=rand()%100+1; result=rand()%8; switch(result){ case 0:printf("%d+%d= ",a,b);break; case 1:printf("%d-%d= ",a,b);break; case 2:printf("%d*%d= ",a,b);break; case 3:printf("%d/%d= ",a,b);break; case 4:printf("%d/%d+%d/%d= ",a,m,b,n);break; case 5:printf("%d/%d-%d/%d= ",a,m,b,n);break; case 6:printf("%d/%d*%d/%d= ",a,m,b,n);break; case 7:printf("%d/%d/%d/%d= ",a,m,b,n);break; } } }
以下是我的复审结果：
1、 概要部分
第二次的作业题目是编写自动生成四则运算的题目，题目包括整数和真分数。我复审的代码基本符合题目的需求，通过执行程序，每行代码都没有问题，可以准确的运行出结果，可读性一般，易维护。但是我认为代码设计考虑的不够周全：
（1）在除法运算中，此程序没有解决除数为0的问题。
（2）分数运算中，没有解决分数为真分数问题。
2、设计规范部分
代码设计流程较规范，不存在无用的代码，整体简洁。
3、代码规范部分
（1）部分代码没有缩进。
（2）虽然程序较短，实现方法简单，但是没有对关键代码注释。
4、具体代码部分
（1）程序中的在命名变量部分使用的是a、b等代名词，这样命名虽简单，但是不能体现它所代表的具体含义，所以在命名时应使用望文生义的英文缩写或拼音缩写。
（2）程序中将所有的代码都写在main（）里面，应该多拆分成多个方法。
5、效能
在我看来，程序中没有明显可优化的部分。
6、可读性
代码简短，功能简单，可读性一般。但是没有足够的注释。
三、P2P
|
PSP2.1 |
Personal software Process stages |
Time Senior student |
|
Planning |
计划 |
6h |
|
·Estimate |
·估计这个任务需要多长时间 |
6h |
|
Development |
开发 |
10min |
|
·Analysis |
·需求分析 |
10min |
|
·Design Spec |
·生成设计文档 |
20min |
|
·Design Review |
·设计复审 |
1h |
|
·Coding Standard |
·代码规范 |
10min |
|
·Design |
·具体设计 |
1h |
|
·Coding |
·具体编码 |
3h |
|
·Code Review |
·代码复审 |
20min |
|
·Test |
·测试 |
20min |
|
Reporting |
报告 |
10min |
|
·Test Report |
·测试报告 |
15min |
|
·Size Measurement |
·计算工作量 |
10min |
|
·Postmortem&Process Improvement Plan |
·事后总结，并提出过程改进计划 |
10min |