JAVA常见面试题之七(转载)

- 作者： like 2006年10月24日, 星期二 15:29　 回复（0） |　 引用（0） 加入博采 

 c语言常见错误 
c语言常见错误
本文来源：happyyangxu.home.sunbo.net 

C语言的最大特点是：功能强、使用方便灵活。C编译的程序对语法检查并不象其它高级语言那么严格，这就给编程人员留下“灵活的余地”，但还是由于这个灵活给程序的调试带来了许多不便，尤其对初学C语言的人来说，经常会出一些连自己都不知道错在哪里的错误。看着有错的程序，不知该如何改起，本人通过对C的学习，积累了一些C编程时常犯的错误，写给各位学员以供参考。 


1.书写标识符时，忽略了大小写字母的区别。 main() { int a=5; printf("%d",A); } 编译程序把a和A认为是两个不同的变量名，而显示出错信息。C认为大写字母和小写字母是两个不同的字符。习惯上，符号常量名用大写，变量名用小写表示，以增加可读性。 
2.忽略了变量的类型，进行了不合法的运算。 main() { float a,b; printf("%d",a%b); } %是求余运算，得到a/b的整余数。整型变量a和b可以进行求余运算，而实型变量则不允许进行“求余”运算。 
3.将字符常量与字符串常量混淆。 char c; c="a"; 在这里就混淆了字符常量与字符串常量，字符常量是由一对单引号括起来的单个字符，字符串常量是一对双引号括起来的字符序列。C规定以“”作字符串结束标志，它是由系统自动加上的，所以字符串“a”实际上包含两个字符：‘a'和‘'，而把它赋给一个字符变量是不行的。 
4.忽略了“=”与“==”的区别。 在许多高级语言中，用“=”符号作为关系运算符“等于”。如在BASIC程序中可以写 if (a=3) then … 但C语言中，“=”是赋值运算符，“==”是关系运算符。如： if (a==3) a=b; 前者是进行比较，a是否和3相等，后者表示如果a和3相等，把b值赋给a。由于习惯问题，初学者往往会犯这样的错误。 
5.忘记加分号。 分号是C语句中不可缺少的一部分，语句末尾必须有分号。 a=1 b=2 编译时，编译程序在“a=1”后面没发现分号，就把下一行“b=2”也作为上一行语句的一部分，这就会出现语法错误。改错时，有时在被指出有错的一行中未发现错误，就需要看一下上一行是否漏掉了分号。 { z=x+y; t=z/100; printf("%f",t); } 对于复合语句来说，最后一个语句中最后的分号不能忽略不写(这是和PASCAL不同的)。 
6.多加分号。 对于一个复合语句，如： { z=x+y; t=z/100; printf("%f",t); }; 复合语句的花括号后不应再加分号，否则将会画蛇添足。又如： if (a%3==0); I++; 本是如果3整除a，则I加1。但由于if (a%3==0)后多加了分号，则if语句到此结束，程序将执行I++语句，不论3是否整除a，I都将自动加1。再如： for (I=0;I<5;I++); {scanf("%d",&x); printf("%d",x);} 本意是先后输入5个数，每输入一个数后再将它输出。由于for()后多加了一个分号，使循环体变为空语句，此时只能输入一个数并输出它。 
7.输入变量时忘记加地址运算符“&”。 int a,b; scanf("%d%d",a,b); 这是不合法的。Scanf函数的作用是：按照a、b在内存的地址将a、b的值存进去。“&a”指a在内存中的地址。 
8.输入数据的方式与要求不符。①scanf("%d%d",&a,&b); 输入时，不能用逗号作两个数据间的分隔符，如下面输入不合法： 3，4 输入数据时，在两个数据之间以一个或多个空格间隔，也可用回车键，跳格键tab。 ②scanf("%d,%d",&a,&b); C规定：如果在“格式控制”字符串中除了格式说明以外还有其它字符，则在输入数据时应输入与这些字符相同的字符。下面输入是合法的： 3，4 此时不用逗号而用空格或其它字符是不对的。 3 4 3：4 又如： scanf("a=%d,b=%d",&a,&b); 输入应如以下形式： a=3,b=4 
9.输入字符的格式与要求不一致。 在用“%c”格式输入字符时，“空格字符”和“转义字符”都作为有效字符输入。 scanf("%c%c%c",&c1,&c2,&c3); 如输入a b c 字符“a”送给c1，字符“ ”送给c2，字符“b”送给c3，因为%c只要求读入一个字符，后面不需要用空格作为两个字符的间隔。 
10.输入输出的数据类型与所用格式说明符不一致。 例如，a已定义为整型，b定义为实型 a=3;b=4.5; printf("%f%dn",a,b); 编译时不给出出错信息，但运行结果将与原意不符。这种错误尤其需要注意。 
11.输入数据时，企图规定精度。 scanf("%7.2f",&a); 这样做是不合法的，输入数据时不能规定精度。 
12.switch语句中漏写break语句。 例如：根据考试成绩的等级打印出百分制数段。 switch(grade) { case 'A':printf("85~100n"); case 'B':printf("70~84n"); case 'C':printf("60~69n"); case 'D':printf("<60n"); default:printf("errorn"); 由于漏写了break语句，case只起标号的作用，而不起判断作用。因此，当grade值为A时，printf函数在执行完第一个语句后接着执行第二、三、四、五个printf函数语句。正确写法应在每个分支后再加上“break;”。例如 case 'A':printf("85~100n");break; 
13.忽视了while和do-while语句在细节上的区别。 (1)main() {int a=0,I; scanf("%d",&I); while(I<=10) {a=a+I; I++; } printf("%d",a); } (2)main() {int a=0,I; scanf("%d",&I); do {a=a+I; I++; }while(I<=10); printf("%d",a); } 可以看到，当输入I的值小于或等于10时，二者得到的结果相同。而当I>10时，二者结果就不同了。因为while循环是先判断后执行，而do-while循环是先执行后判断。对于大于10的数while循环一次也不执行循环体，而do-while语句则要执行一次循环体。 
14.定义数组时误用变量。 int n; scanf("%d",&n); int a[n]; 数组名后用方括号括起来的是常量表达式，可以包括常量和符号常量。即C不允许对数组的大小作动态定义。 
15.在定义数组时，将定义的“元素个数”误认为是可使的最大下标值。 main() {static int a[10]={1,2,3,4,5,6,7,8,9,10}; printf("%d",a[10]); } C语言规定：定义时用a[10]，表示a数组有10个元素。其下标值由0开始，所以数组元素a[10]是不存在的。 
16.初始化数组时，未使用静态存储。 int a[3]={0,1,2}; 这样初始化数组是不对的。C语言规定只有静态存储(static)数组和外部存储(exterm)数组才能初始化。应改为： static int a[3]={0,1,2}; 17.在不应加地址运算符&的位置加了地址运算符。 scanf("%s",&str); C语言编译系统对数组名的处理是：数组名代表该数组的起始地址，且scanf函数中的输入项是字符数组名，不必要再加地址符&。应改为： scanf("%s",str); 
18.同时定义了形参和函数中的局部变量。 int max(x,y) int x,y,z; {z=x>y?x:y; return(z); } 形参应该在函数体外定义，而局部变量应该在函数体内定义。应改为： int max(x,y) int x,y; {int z; z=x>y?x:y; return(z);} 
- 作者： like 2006年09月17日, 星期日 11:19　 回复（0） |　 引用（0） 加入博采 

 c语言数据类型 
c语言数据类型

本文来源：vcok.com 

所谓数据类型是按被说明量的性质，表示形式，占据存储空间的多少，构造特点来划分的。在Ｃ语言中，数据类型可分为：基本数据类型，构造数据类型，指针类型，空类型四大类。 
1.基本数据类型 基本数据类型最主要的特点是，其值不可以再分解为其它类型。也就是说，基本数据类型是自我说明的。 
对于基本数据类型量，按其取值是否可改变又分为常量和变量两种。在程序执行过程中，其值不发生改变的量称为常量，取值可变的量称为变量。它们可与数据类型结合起来分类。例如，可分为整型常量、整型变量、浮点常量、浮点变量、字符常量、字符变量、枚举常量、枚举变量。在程序中，常量是可以不经说明而直接引用的，而变量则必须先说明后使用。 

整型量 整型量包括整型常量、整型变量。 

整型常量 整型常量就是整常数。在Ｃ语言中，使用的整常数有八进制、十六进制和十进制三种。 
1.八进制整常数  八进制整常数必须以0开头，即以0作为八进制数的前缀。数码取值为0～7。八进制数通常是无符号数。以下各数是合法的八进制数： 015(十进制为13)　0101(十进制为65)　0177777(十进制为65535) 以下各数不是合法的八进制数： 256(无前缀0) 03A2(包含了非八进制数码)　-0127(出现了负号) 
2.十六进制整常数   十六进制整常数的前缀为0X或0x。其数码取值为0~9，A~F或a~f。以下各数是合法的十六进制整常数： 0X2A(十进制为42)　　0XA0 (十进制为160)　　0XFFFF (十进制为65535) 以下各数不是合法的十六进制整常数： 5A (无前缀0X)　　0X3H (含有非十六进制数码)

3.十进制整常数   十进制整常数没有前缀。其数码为0～9。以下各数是合法的十进制整常数： 237 -568 65535 1627 以下各数不是合法的十进制整常数： 023 (不能有前导0)　23D (含有非十进制数码) 在程序中是根据前缀来区分各种进制数的。因此在书写常数时不要把前缀弄错造成结果不正确。

4.整型常数的后缀在16位字长的机器上，基本整型的长度也为16位，因此表示的数的范围也是有限定的。十进制无符号整常数的范围为0～65535，有符号数为-32768～+32767。八进制无符号数的表示范围为0～0177777。十六进制无符号数的表示范围为0X0～0XFFFF或0x0～0xFFFF。如果使用的数超过了上述范围，就必须用长整型数来表示。长整型数是用后缀“L”或“l”来表示的。
例如：十进制长整常数 158L (十进制为158) 358000L (十进制为-358000) 八进制长整常数 012L (十进制为10) 077L (十进制为63)　0200000L (十进制为65536) 十六进制长整常数 0X15L (十进制为21) 0XA5L (十进制为165)　0X10000L (十进制为65536) 长整数158L和基本整常数158 在数值上并无区别。但对158L，因为是长整型量，Ｃ编译系统将为它分配4个字节存储空间。而对158，因为是基本整型，只分配2 个字节的存储空间。因此在运算和输出格式上要予以注意，避免出错。无符号数也可用后缀表示，整型常数的无符号数的后缀为“U”或“u”。
例如： 358u,0x38Au,235Lu 均为无符号数。前缀，后缀可同时使用以表示各种类型的数。如0XA5Lu表示十六进制无符号长整数A5，其十进制为165。


整型变量 整型变量可分为以下几类：
1.基本型   类型说明符为int，在内存中占2个字节，其取值为基本整常数。 
2.短整量   类型说明符为short int或short'C110F1。所占字节和取值范围均与基本型相同。 
3.长整型   类型说明符为long int或long ，在内存中占4个字节，其取值为长整常数。 
4.无符号型   类型说明符为unsigned。无符号型又可与上述三种类型匹配而构成： (1)无符号基本型 类型说明符为unsigned int或unsigned。 (2)无符号短整型 类型说明符为unsigned short (3)无符号长整型 类型说明符为unsigned long 各种无符号类型量所占的内存空间字节数与相应的有符号类型量相同。但由于省去了符号位，故不能表示负数。 

在书写变量说明时，应注意以下几点： 
1.允许在一个类型说明符后，说明多个相同类型的变量。各变量名之间用逗号间隔。类型说明符与变量名之间至少用一个空格间隔。 
2.最后一个变量名之后必须以“；”号结尾。 
3.变量说明必须放在变量使用之前。一般放在函数体的开头部分。

实型量 包括实型常量和实型变量。 

实型常量 实型常量也称为实数或者浮点数。在Ｃ语言中，实数只采用十进制。它有二种形式： 十进制数形式指数形式 
1.十进制数形式由数码0~ 9和小数点组成。例如：0.0，.25，5.789，0.13，5.0，300.，-267.8230等均为合法的实数。 
2.指数形式由十进制数，加阶码标志“e”或“E”以及阶码（只能为整数，可以带符号）组成。其一般形式为a E n （a为十进制数，n为十进制整数）其值为 a*10,n　如： 2.1E5 (等于2.1*10,5), 3.7E-2 (等于3.7*10,)-2*)　0.5E7 (等于0.5*10,7), -2.8E-2 (等于-2.8*10,)-2*)以下不是合法的实数 345 (无小数点)　E7 (阶码标志E之前无数字)　 -5 (无阶码标志)　53.-E3 (负号位置不对)　2.7E (无阶码) 标准Ｃ允许浮点数使用后缀。后缀为“f”或“F”即表示该数为浮点数。如356f和356.是等价的。下例说明了这种情况： 
void main() 
{ 
printf("%f\n%f\n",356.,356f); 
} 
void 指明main不返回任何值　利用printf显示结果　结束

实型变量 实型变量分为两类：单精度型和双精度型.
其类型说明符为float 单精度说明符，double 双精度说明符。在Turbo C中单精度型占4个字节（32位）内存空间，其数值范围为3.4E-38～3.4E+38，只能提供七位有效数字。双精度型占8 个字节（64位）内存空间，其数值范围为1.7E-308～1.7E+308，可提供16位有效数字。实型变量说明的格式和书写规则与整型相同。 
例如： float x,y; (x,y为单精度实型量) 　　　 
double a,b,c; (a,b,c为双精度实型量) 实型常数不分单、双精度，都按双精度double型处理。 
字符型量 字符型量包括字符常量和字符变量。 

字符常量 字符常量是用单引号括起来的一个字符。例如'a','b','=','+','?'都是合法字符常量。在Ｃ语言中，字符常量有以下特点： 
1.字符常量只能用单引号括起来，不能用双引号或其它括号。 
2.字符常量只能是单个字符，不能是字符串。 
3.字符可以是字符集中任意字符。但数字被定义为字符型之后就不能参与数值运算。如'5'和5 是不同的。'5'是字符常量，不能参与运算。 

转义字符 转义字符也是一种特殊的字符常量。转义字符以反斜线"\"开头，后跟一个或几个字符。转义字符具有特定的含义，不同于字符原有的意义，故称“转义”字符。例如，在前面各例题printf函数的格式串中用到的“\n”就是一个转义字符，其意义是“回车换行”。转义字符主要用来表示那些用一般字符不便于表示的控制代码。常用的转义字符及其含义 
\n    　　　　　回车换行 
\t    　　　　　横向跳到下一制表位置 
\v    　　　　　竖向跳格 
\b    　　　　　退格 
\r    　　　　　回车 
\f   　　　　 　走纸换页 
\\    　　　　　反斜线符"\" 
\'    　　　　　单引号符 
\a    　　　　　鸣铃 
\ddd    　　　　1～3位八进制数所代表的字符 
\xhh    　　　　1～2位十六进制数所代表的字符 
广义地讲，Ｃ语言字符集中的任何一个字符均可用转义字符来表示。 


字符变量 字符变量的取值是字符常量，即单个字符。字符变量的类型说明符是char。字符变量类型说明的格式和书写规则都与整型变量相同。

字符串常量是由一对双引号括起的字符序列。例如： "CHINA" ，"C program: ， "$12.5" 等都是合法的字符串常量。字符串常量和字符常量是不同的量。它们之间主要有以下区别： 
1.字符常量由单引号括起来，字符串常量由双引号括起来。 
2.字符常量只能是单个字符，字符串常量则可以含一个或多个字符。 
3.可以把一个字符常量赋予一个字符变量，但不能把一个字符串常量赋予一个字符变量。在Ｃ语言中没有相应的字符串变量。这是与BASIC 语言不同的。但是可以用一个字符数组来存放一个字符串常量。在数组一章内予以介绍。 
4.字符常量占一个字节的内存空间。字符串常量占的内存字节数等于字符串中字节数加1。增加的一个字节中存放字符"\0"(ASCII码为0)。这是字符串结束的标志。例如，字符串 "C program"在内存中所占的字节为：C program\0。字符常量'a'和字符串常量"a"虽然都只有一个字符，但在内存中的情况是不同的。 
'a'在内存中占一个字节，可表示为：a 
"a"在内存中占二个字节，可表示为：a\0符号常量 

符号常量 在Ｃ语言中，可以用一个标识符来表示一个常量，称之为符号常量。 
符号常量在使用之前必须先定义，其一般形式为： 
#define 标识符 常量 其中#define也是一条预处理命令（预处理命令都?quot;#"开头），称为宏定义命令（在第九章预处理程序中将进一步介绍），其功能是把该标识符定义为其后的常量值。一经定义，以后在程序中所有出现该标识符的地方均代之以该常量值。习惯上符号常量的标识符用大写字母，变量标识符用小写字母，以示区别。 
#define PI 3.14159 
void main(){ 
float s,r; 
r=5; 
s=PI*r*r; 
printf("s=%f\n",s); 
} 
由宏定义命令定义PI 为3.14159 s,r定义为实数　5->r　PI*r*r->s 
显示程序结果 float s,r;　r=5;　s=PI*r*r; 本程序在主函数之前由宏定义命令定义PI 为3.14159，在程序中即以该值代替PI 。s=PI*r*r等效于s=3.14159*r*r。应该注意的是，符号常量不是变量，它所代表的值在整个作用域内不能再改变。也就是说，在程序中，不能再用赋值语句对它重新赋值。 


2.构造数据类型 是根据已定义的一个或多个数据类型用构造的方法来定义的。也就是说，一个构造类型的值可以分解成若干个“成员”或“元素”。每个“成员”都是一个基本数据类型或又是一个构造类型。在C语言中，构造类型有以下几种： 
·数组类型 
·结构类型 
·联合类型 
3.指针类型 指针是一种特殊的，同时又是具有重要作用的数据类型。其值用来表示某个量在内存储器中的地址。虽然指针变量的取值类似于整型量，但这是两个类型完全不同的量，因此不能混为一谈。 
4.空类型 在调用函数值时，通常应向调用者返回一个函数值。这个返回的函数值是具有一定的数据类型的，应在函数定义及函数说明中给以说明，但是，也有一类函数，调用后并不需要向调用者返回函数值， 这种函数可以定义为“空类型”。其类型说明符为void。 

- 作者： like 2006年09月17日, 星期日 10:28　 回复（0） |　 引用（0） 加入博采 

 多个参数遇到的问题 
我在使用ajax中，涉及到一个url中多个参数处理的问题：
出现错误：
[Fatal Error] :1:135: The reference to entity "Type" must end with the ';' delimiter.
或
[Fatal Error] :1:131: The entity name must immediately follow the '&' in the entity reference.
原因：是SAX解析器出错，是XML的问题。
使用"&"代替"&"，原理和HTML中的转义相同，参照XML的语法规范。 
- 作者： like 2006年09月15日, 星期五 14:24　 回复（0） |　 引用（0） 加入博采 

 一个随机排列的程序 
摘要：自己写的一个可以生成n个数的一个随机排列的程序.　查看全文 
- 作者： like 2005年12月1日, 星期四 09:47　 回复（0） |　 引用（0） 加入博采 

 powerbuilder8.0下的版本控制软件vss 
摘要：pb8下的版本控制软件vss　查看全文 
- 作者： like 2005年08月13日, 星期六 00:05　 回复（0） |　 引用（0） 加入博采 

 windows下安装Bugzilla 2.18 
摘要：windows下安装Bugzilla 2.18　查看全文 
- 作者： like 2005年08月12日, 星期五 23:25　 回复（0） |　 引用（0） 加入博采 

 常用log4j配置 
摘要：常用log4j配置　查看全文 
- 作者： cnlike 2005年08月2日, 星期二 21:32　 回复（0） |　 引用（0） 加入博采 

 开发75条（写的不错） 选择自 churujianghu 的 Blog 
开发75条： 
1. 你们的项目组使用源代码管理工具了么？

应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。

 2. 你们的项目组使用缺陷管理系统了么？

应该用。ClearQuest太复杂，我的推荐是BugZilla。 

3. 你们的测试组还在用Word写测试用例么？

不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。 

4. 你们的项目组有没有建立一个门户网站？

要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。 

5. 你们的项目组用了你能买到最好的工具么？

应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。 

6. 你们的程序员工作在安静的环境里么？

需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。 

7. 你们的员工每个人都有一部电话么？需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。 

8. 你们每个人都知道出了问题应该找谁么？

应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。

 9. 你遇到过有人说“我以为…”么？

要消灭“我以为”。Never assume anything。 

10. 你们的项目组中所有的人都坐在一起么？

需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。 

11. 你们的进度表是否反映最新开发进展情况？ 

应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

 12. 你们的工作量是先由每个人自己估算的么？

应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。 

13. 你们的开发人员从项目一开始就加班么？

不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。 

14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？

不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。 

15. 值得再多花一些时间，从95%做到100%好值得，非常值得。

尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。 

16. 登记新缺陷时，是否写清了重现步骤？

要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。 

17. 写新代码前会把已知缺陷解决么？要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。 

18. 你们对缺陷的轻重缓急有事先的约定么？

必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

 19. 你们对意见不一的缺陷有三国会议么？必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。 

20. 所有的缺陷都是由登记的人最后关闭的么？ 

Bug应该由Opener关闭。Dev不能私自关闭Bug。 

21. 你们的程序员厌恶修改老的代码么？

厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。 

22. 你们项目组有Team Morale Activity么？

每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。 

23. 你们项目组有自己的Logo么？

要有自己的Logo。至少应该有自己的Codename。 

24. 你们的员工有印有公司Logo的T-Shirt么？

要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。

 25. 总经理至少每月参加次项目组会议要的。

要让team member觉得高层关注这个项目。 

26. 你们是给每个Dev开一个分支么？

反对。Branch的管理以及Merge的工作量太大，而且容易出错。 

27. 有人长期不Check-In代码么？

不可以。对大部分项目来说，最多两三天就应该Check-In。 

28. 在Check-In代码时都填写注释了么？

要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。

 29. 有没有设定每天Check-In的最后期限？

要的，要明确Check-In Deadline。否则会Build Break。 

30. 你们能把所有源码一下子编译成安装文件吗？ 

要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。 

31. 你们的项目组做每日编译么？

当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。 

32. 你们公司有没有积累一个项目风险列表？

要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。

 33. 设计越简单越好越简单越好。

设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。 

34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。 

35. 你们会隔一段时间就停下来夯实代码么？

要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。 

36. 你们的项目组每个人都写Daily Report么？

要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。

 37. 你们的项目经理会发出Weekly Report么？

要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。

 38. 你们项目组是否至少每周全体开会一次？

要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。 

39. 你们项目组的会议、讨论都有记录么？

会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。

 40. 其他部门知道你们项目组在干什么么？

要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。 

41. 通过Email进行所有正式沟通 

Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。 

42. 为项目组建立多个Mailing Group 

如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。 

43. 每个人都知道哪里可以找到全部的文档么？

应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。 

44. 你做决定、做变化时，告诉大家原因了么？

要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。 

45. Stay agile anｄ expect change 要这样。

需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。 

46. 你们有没有专职的软件测试人员？

要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。 

47. 你们的测试有一份总的计划来规定做什么和怎么做么？这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。

 48. 你是先写Test Case然后再测试的么？

应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。 

49. 你是否会为各种输入组合创建测试用例？

不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。 

50. 你们的程序员能看到测试用例么？

要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。

 51. 你们是否随便抓一些人来做易用性测试？ 

要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。 

52. 你对自动测试的期望正确么？

别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。 

53. 你们的性能测试是等所有功能都开发完才做的么？

不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。 

54. 你注意到测试中的杀虫剂效应了么？

虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。

 55. 你们项目组中有人能说出产品的当前整体质量情况么？

要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。 

56. 你们有单元测试么？

单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。 

57. 你们的程序员是写完代码就扔过墙的么？

大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。

 58. 你们的程序中所有的函数都有输入检查么？

不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。

 59. 产品有统一的错误处理机制和报错界面么？

要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。 

60. 你们有统一的代码书写规范么？

要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。 

61. 你们的每个人都了解项目的商业意义么？

要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。

 62. 产品各部分的界面和操作习惯一致么？

要这样。要让用户觉得整个程序好像是一个人写出来的那样。

 63. 有可以作为宣传亮点的Cool Feature么？

要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。 

64. 尽可能缩短产品的启动时间要这样。

软件启动时间（Start-Up time）是客户对性能好坏的第一印象。

 65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。

 66. 你们根据详细产品功能说明书做开发么？

要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。 

67. 开始开发和测试之前每个人都仔细审阅功能设计么？

要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧” 

68. 所有人都始终想着The Whole Image么？要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。

 69. Dev工作的划分是单纯纵向或横向的么？

不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。 

70. 你们的程序员写程序设计说明文档么？

要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。

 71. 你在招人面试时让他写一段程序么？

要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。 

72. 你们有没有技术交流讲座？

要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。 

73. 你们的程序员都能专注于一件事情么？

要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。 

74. 你们的程序员会夸大完成某项工作所需要的时间么？

会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。 

75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。

Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。

我现在做的项目是采用如下方法管理的：
BD：基础设计。在这个文档里，我们把程序的界面全部画出来；界面上的功能全部描述完整。如：一个查询界面的条件是什么，查询出来的结果如何显示等等。
FD：功能设计。在这个文档里，对BD阶段的各个页面里包含的数据逻辑处理做说明。如：查询时调用的数据处理函数该如何设计，入口参数，返回参数，关联的表等等各方面的说明。

因为程序的界面已经定了，数据处理逻辑也定了。所以，就开始编码阶段。当编码过程中发生什么问题，程序的整个功能还是必须满足BD和FD设计文档中的要求。程序中的各种疑问，都以BD和FD文档中的说明为准。
基本上我们一个小项目的开发周期为2个月，BD为2-3周，FD1周，PG（编程）2-3周，CT(测试)2周。

测试完毕后交出去的就是成品，基本上不会再有系统要求变更的问题了。如果有变更，且不在BD设计范围内，那就是新增需求。就是一个新项目了。

以上资料，仅供参考。