王咏刚，2003年12月


写作本文的初衷是想和大家分享垃圾收集（ Garbage Collection ）技术简单而有趣的发展史。动笔之前，我站在窗边，望了望正在小区里装运垃圾的清洁车。和生活中环卫工人们清运垃圾的工作相似，软件开发里的垃圾收集其实就是一种自动打扫和清除内存垃圾的技术，它可以有效防范动态内存分配中可能发生的两个危险：因内存垃圾过多而引发的内存耗尽（这和生活垃圾堵塞排污管道的危险并没有什么本质的不同），以及不恰当的内存释放所造成的内存非法引用（这类似于我们在生活中买到了一瓶已经过期三年的牛奶）。

据历史学家们介绍，四千多年前的古埃及人已经在城市里建设了完善的排污和垃圾清运设施，一千多年前的中国人更是修筑了当时世界上保洁能力最强的都市 ——长安。今天，当我们在软件开发中体验自动垃圾收集的便捷与舒适时，我们至少应当知道，这种拒绝杂乱、追求整洁的“垃圾收集”精神其实是人类自古以来就已经具备了的。

本文内容来自网络，但不知道原创和出处

本文中，我将针对这些看似怪异的最佳实践阐述我的观点，并简述我对实施这些最佳实践的一些思考。

一、计划游戏

能够把计划叫做“游戏”是需要一定勇气的。在传统的软件开发方法学中，计划是举足轻重的一环，在制订计划前需要仔细的估算，在计划实施的过程中，还要不停的跟踪、修正，直至整个项目完成。

而在XP中，计划似乎要轻松许多。这并不是因为计划本身变得草率和无关痛痒，而是得益于XP的小版本发布思维。软件的一个版本是如此短小简单，以至于对它进行完整的评估、预算、跟踪和修正要容易许多。事实上，XP中采用的计划方式（业务人员和开发人员共同参与，各司其职）在大多数现代软件企业中早已采用，但是由于项目过于庞大，很难在开始阶段制订出完善的计划。而在XP中，人们只需要针对一个一两个月的小项目进行跟踪和管理，无形中降低了计划的风险。

二、隐喻

    在XP中，人们经常会使用隐喻来代替传统开发过程中的体系结构设计。从指导开发的角度来说，隐喻似乎不够精确，容易让人误解。但是，对于具有类似背景的同一个项目组中的开发人员来说，隐喻则更便于理解和交流。很难想象两个程序员面对着一张庞大的体系结构图时能够真正有效的沟通，而隐喻很好的解决了这个问题。

三、简单设计

不知道从什么时候开始，开发人员习惯了为明天而设计。一个开发人员设计了一个复杂的类继承结构，只是为了提高程序的所谓灵活性。没人知道这样值不值，并不是软件的每一个部分都需要扩展。但是，对于传统的软件开发人员来说，这么做又是迫不得已。如果没有预先做好准备，在变化来临时就会措手不及，付出沉重的代价。

但是在XP中，小版本发行的方法使得变化并不那么可怕，而重构的广泛采用，使得代码总是可以在需要时变得更加灵活。此外，由于你的代码总是会被别人审查（代码集体所有权和结对编程），因此也可以避免过于追求简单而忽视了重要的细节。

四、测试优先

没有代码要测试程序有什么用？这是测试优先最容易让人误解的地方。测试优先能够让开发人员更清楚的认识到，程序将会如何被使用。通过对不同的测试用例的思考，开发人员也能够更清晰的认识到程序的功能外延。而更多的其他的开发人员，则通过测试用例就可以获得一份精确的使用手册，在这份使用手册中，描述了作者考虑到的所有输入和输出结果，这样不仅便于人们了解程序，更增加了发现程序错误的机会（缺失的测试用例往往体现出作者忽视的某些使用情况）。

五、结对编程

两个程序员坐在一起，能够提高开发效率吗？程序员难道不是一群高傲的猫，习惯于离群索居，把头抬得高高吗？

事实并非如此。在一个正确的、合理的、能够实现的大目标下，程序员们不仅能够和平共处，更可以相互合作，创造出优秀的、高质量的程序。沟通一直是软件项目管理中的一个重要议题，而结对编程提供了一个十分有效的沟通渠道。此外，结对编程也更容易让新人融入团体。在几个高级程序员的指引下，他会更容易找出程序的脉络，把握程序的思想。较之正规的培训，这种方式更轻松也更有效。对于团队中的所有程序员来说，结对编程都是一个了解其他人设计思想的机会，通过结对编程，能够更好的实现代码集体所有权，也能够降低因为人员流动造成的风险。

结对编程最大的好处在于，能够极大的减少程序中潜在变化的可能性。两个人通过交流互相交换自己对程序的不同理解，更容易找出程序中可能出现的变化或错误，从而使程序更加可靠和健壮。

六、持续集成

集成一直是最费力的工作之一，本来工作的好好的代码，放在一起就不能运转，更糟糕的是成百上千条不知所云的错误码，没有人知道这些错误码来自何处。这是每个项目几乎都会遇到的最困难的阶段，程序员们必须集合在一起，翻阅数量巨大的接口定义文件，反复查看代码，同时还要不断的做出承诺。

持续集成正是解决上述问题的方法。通过多次、小增量的集成，我们总是能够以最快的速度定位错误出现的位置（因为增加的代码很少），结合大量测试用例，我们也可以确保每一个集成版本都尽可能的可靠。

此外，持续集成几乎可以在任何时间向我们提供一个可以工作的版本，我们可以将这个版本用于内部讨论和测试、客户展示、客户测试、小版本发布等等，这使得我们不需要花费太多的时间对现有的程序修修补补，以生成一个demo。

上文简单叙述了XP中常会引起争议的六个最佳实践的优点。下面本文将结合实际谈谈实施XP中需要注意的一些问题。

一、适用性问题

XP理论在提出时，明确的说明：XP是适用于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法。这就意味着，XP并不适用于所有情况。在准备实施XP前，你也许需要仔细评估项目的具体情况，以决定是否真的需要采用XP。

二、最佳实践间的关联

XP的一个特点是，它所推崇的最佳实践几乎总是和其它实践关联紧密，在实施一项最佳实践时，如果不同时实施其它实践，往往难以达到最初的目的。因此，在实施XP时，需要仔细研究各项实践间的关联，以确定最佳的实施方案。

三、宽松的环境

XP是一种追求自然的工作方法。它所倡导的是，程序员们以最自然开发的方式完成他们的工作。对于习惯了传统开发方法严格管理制度的管理人员来说，这往往是很难接受的。于是就出现了，虽然最高决策人决定实施XP，但管理层却无法（或不愿）给开发人员提供宽松的环境。在一个古板僵化的方框里，开发人员不会真正的回复自然，他们会装作正在实践XP，但事实上，他们依然在老路上行走（可以见到很多这样的例子，比如一些虚张声势的测试用例等等）。

四、忍受变化

XP对于传统软件项目管理思想的冲击，可能会使很多管理人员感到不舒服。也许XP一经实施，就会给项目组带来翻天覆地的变化。如果这样的变化让你感到恐惧，那么请暂时忍耐，你不能肯定这种变化不好，除非你亲眼看到。到那时再决定也不迟。

五、慢慢来

实施XP的过程不能操之过急。最好的方法是，在部分项目组中先行实施，实施时也不需要同时实施所有实践（但要注意各个实践间的关联问题）。有的时候你会发现，在实施了部分实践后，其它的实践也成为水到渠成的事情。当经过仔细评估，确信XP在项目组中确实有效后，再逐步在企业范围内推广，必要的时候，需要采取自愿的原则，由项目组的成员决定是否需要实施XP。

以上即是我在软件工程过程课程中以及平时工作、学习中对XP的一些认识。

来源： http://blog.csdn.net/leasun/archive/2006/08/15/1067508.aspx

                                       关于 sizeof() 的一些思考 
                                                         马嘉楠

关键词： sizeof

这是网上的一个帖子，最初来自那里已经记不得了，不过我觉得很不错。

我对原文做了一些修改，并添加了一些内容。如果有什么错误的地方，请大家指正，谢谢~~

                       --- majianan 2005-12-19

0.关键字 ：sizeof，字节对齐，类型大小

前向声明：
    sizeof，一个其貌不扬的家伙，引无数菜鸟竟折腰.

    小虾我当初也没少犯迷糊，秉着“辛苦我一个，幸福千万人”的伟大思想,我决定将其尽可能详细的总结一下。

    但当我总结的时候才发现，这个问题既可以简单，又可以复杂。所以本文有的地方并不适合初学者，甚至都没有必要大作文章。但如果你想“知其然，更知其所以然”的话，那么这篇文章对你或许有所帮助。
   

    菜鸟我对C++的掌握尚未深入，其中不乏错误，欢迎各位指正啊

1. 定义：
    sizeof是何方神圣？

    sizeof 乃 C/C++ 中的一个操作符（operator）是也。简单说其作用就是返回一个对象或者类型所占的内存字节数。

MSDN上的解释为：

The sizeof keyword gives the amount of storage, in bytes, associated with a variable or a type (including aggregate types).This keyword returns a value of type size_t.

    其返回值类型为size_t，在头文件stddef.h中定义。这是一个依赖于编译系统的值，一般定义为

typedef unsigned int size_t;

    世上编译器林林总总，但作为一个规范，它们都会保证char、signed char和unsigned char的sizeof值为1，毕竟char是我们编程能用的最小数据类型。

2. 语法：
    sizeof有三种语法形式，如下：
    1) sizeof( object );    // sizeof( 对象 );
    2) sizeof( type_name ); // sizeof( 类型 );
    3) sizeof object;       // sizeof 对象;

所以，
int i;
sizeof( i );     // ok
sizeof i;        // ok
sizeof( int );   // ok
sizeof int;      // error

既然写法2可以用写法1代替，为求形式统一以及减少我们大脑的负担，第2种写法，忘掉它吧！

实际上，sizeof计算对象的大小也是转换成对对象类型的计算。也就是说，同种类型的不同对象其sizeof值都是一致的。

这里，对象可以进一步延伸至表达式，即sizeof可以对一个表达式求值。编译器根据表达式的最终结果类型来确定大小，一般不会对表达式进行计算。

例如：

sizeof( 2 );        // 2的类型为int，所以等价于 sizeof( int );
sizeof( 2 + 3.14 ); // 3.14的类型为double，2也会被提升成double类型，所以等价于 sizeof( double );

    sizeof也可以对一个函数调用求值，其结果是函数返回类型的大小，函数并不会被调用。我们来看一个完整的例子：

*********************************************************

char foo()
{
    printf("foo() has been called.\n");
    return 'a';
}
int main()
{
    size_t sz = sizeof( foo() );   // foo() 的返回值类型为char，所以sz = sizeof(char)，但函数foo()并不会被调用
    printf("sizeof( foo() ) = %d\n", sz);
}

*********************************************************

C99标准规定，函数、不能确定类型的表达式以及位域（bit-field）成员不能被计算sizeof值，即下面这些写法都是错误的：

    sizeof( foo );     // error
    void foo2() { }
    sizeof( foo2() );  // error
    struct S
    {
        unsigned int f1 : 1;
        unsigned int f2 : 5;
        unsigned int f3 : 12;
    };
    sizeof( S.f1 );   // error

3. sizeof的常量性

    sizeof的计算发生在编译时刻，所以它可以被当作常量表达式使用。如：

char ary[ sizeof( int ) * 10 ];   // ok

最新的C99标准规定sizeof也可以在运行时刻进行计算。如下面的程序在Dev-C++中可以正确执行：

int n;
n = 10;        // n动态赋值
char ary[n];   // C99也支持数组的动态定义
printf("%d\n", sizeof(ary)); // ok. 输出10

但在没有完全实现C99标准的编译器中就行不通了，上面的代码在VC6中就通不过编译。所以我们最好还是认为sizeof是在编译期执行的，这样不会带来错误，让程序的可移植性强些。

4. 基本数据类型的sizeof

这里的基本数据类型指short、int、long、float、double这样的简单内置数据类型。由于它们都是和系统相关的，所以在不同的系统下取值可能不同。这务必引起我们的注意，尽量不要在这方面给自己程序的移植造成麻烦。

一般的，在32位编译环境中，sizeof(int)的取值为4。

5. 指针变量的sizeof

学过数据结构的你应该知道指针是一个很重要的概念，它记录了另一个对象的地址。既然是来存放地址的，那么它当然等于计算机内部地址总线的宽度。所以在32位计算机中，一个指针变量的返回值必定是4（注意结果是以字节为单位）。可以预计，在将来的64位系统中指针变量的sizeof结果为8。

*********************************************************

char* pc = "abc";
int* pi;
string* ps;
char** ppc = &pc;
void (*pf)(); // 函数指针
sizeof( pc ); // 结果为4
sizeof( pi ); // 结果为4
sizeof( ps ); // 结果为4
sizeof( ppc );// 结果为4
sizeof( pf ); // 结果为4

*********************************************************

指针变量的sizeof值与指针所指的对象没有任何关系，正是由于所有的指针变量所占内存大小相等，所以MFC消息处理函数使用两个参数WPARAM、LPARAM就能传递各种复杂的消息结构（使用指向结构体的指针）。

6. 数组的sizeof

数组的sizeof值等于数组所占用的内存字节数，如：

char a1[] = "abc";
int a2[3];
sizeof( a1 ); // 结果为4，字符 末尾还存在一个NULL终止符
sizeof( a2 ); // 结果为3*4=12（依赖于int）

一些朋友刚开始时把sizeof当作了求数组元素的个数，现在，你应该知道这是不对的。那么应该怎么求数组元素的个数呢？

Easy，通常有下面两种写法：

int c1 = sizeof( a1 ) / sizeof( char );    // 总长度/单个元素的长度
int c2 = sizeof( a1 ) / sizeof( a1[0]);    // 总长度/第一个元素的长度

写到这里，提一问，下面的c3，c4值应该是多少呢？

*********************************************************

void foo3(char a3[3])
{
    int c3 = sizeof( a3 ); // c3 ==
}
void foo4(char a4[])
{
    int c4 = sizeof( a4 ); // c4 ==
}

*********************************************************

也许当你试图回答c4的值时已经意识到c3答错了，是的，c3!=3。

这里函数参数a3已不再是数组类型，而是蜕变成指针。相当于char* a3，为什么仔细想想就不难明白。

我们调用函数foo1时，程序会在栈上分配一个大小为3的数组吗？不会！

数组是“传址”的，调用者只需将实参的地址传递过去，所以a3自然为指针类型（char*），c3的值也就为4。

7.string的sizeof
一个string的大小与它所指向的字符串的长度无关。

*********************************************************
string st1("blog.sina.com.cn");
string st2("majianan");
string st3;
string *ps = &st1;
cout << "st1: " << sizeof(st1) << endl;
cout << "st2: " << sizeof(st2) << endl;
cout << "st3: " << sizeof(st3) << endl;
cout << "ps: " << sizeof(ps) << endl;
cout << "*ps: " << sizeof(*ps) << endl;
*********************************************************

输出结果为：
st1： 28
st2： 28
st3： 28
ps： 4
*ps： 28
*********************************************************
对于不同的STL，String类的结构定义会有所不同
所以不同的工具，例如VC++，和.NET，结果会有所不同，
在VC++6.0中（我的机器）结果是16
在.NET2003中结果是28
但是对于同一个编译器，那么它的结果都是一定的


8.引用的sizeof

sizeof操作符应用在引用类型上的时候，返回的是包含被引用对象所需的内存长度（即被引用对象的大小）

*********************************************************
cout << "short:\t" << sizeof(short) << endl;
cout << "short*:\t" << sizeof(short*) << endl;
cout << "short&:\t" << sizeof(short&) << endl;
cout << "short[4]:\t" << sizeof(short[4]) << endl;
cout << "int&:\t" << sizeof(int&) << endl;
*********************************************************

输出结果为：
short： 2
short*： 4
short&： 2
short[4]： 8
int&： 4


9. 结构体的sizeof

这是初学者问得最多的一个问题，所以这里有必要多费点笔墨。让我们先看一个结构体：

struct S1
{
    char c;
    int i;
};

问sizeof(s1)等于多少？

聪明的你开始思考了，char占1个字节，int占4个字节，那么加起来就应该是5。

是这样吗？

你在你机器上试过了吗？

也许你是对的，但很可能你是错的！

VC6中按默认设置得到的结果为8。

    Why？为什么受伤的总是我？

请不要沮丧，我们来好好琢磨一下sizeof的定义 —— sizeof的结果等于对象或者类型所占的内存字节数。好吧，那就让我们来看看S1的内存分配情况：

S1 s1 = { 'a', 0xFFFFFFFF };

定义上面的变量后，加上断点，运行程序，观察s1所在的内存，你发现了什么？

以我的VC6.0为例，s1的地址为0x0012FF78，其数据内容如下：

0012FF78: 61 CC CC CC FF FF FF FF

发现了什么？怎么中间夹杂了3个字节的CC？

看看MSDN上的说明：

When applied to a structure type or variable, sizeof returns the actual size, which may include padding bytes inserted for alignment.

原来如此，这就是传说中的字节对齐啊！一个重要的话题出现了。

为什么需要字节对齐？

计算机组成原理教导我们，这样有助于加快计算机的取数速度，否则就得多花指令周期了。

为此，编译器默认会对结构体进行处理（实际上其它地方的数据变量也是如此），让宽度为2的基本数据类型（short等）都位于能被2整除的地址上，让宽度为4的基本数据类型（int等）都位于能被4整除的地址上。以此类推，这样，两个数中间就可能需要加入填充字节，所以整个结构体的sizeof值就增长了。

让我们交换一下S1中char与int的位置：

struct S2
{
    int i;
    char c;
};

看看sizeof(S2)的结果为多少？怎么还是8。

再看看内存，原来成员c后面仍然有3个填充字节。

这又是为什么啊？别着急，下面总结规律。

    字节对齐的细节和编译器实现相关，但一般而言，满足三个准则：
    1) 结构体变量的首地址能够被其最宽基本类型成员的大小所整除；
    2) 结构体每个成员相对于结构体首地址的偏移量（offset）都是成员大小的整数倍，如有需要编译器会在成员之间加上填充字节（internal adding）；
    3) 结构体的总大小为结构体最宽基本类型成员大小的整数倍，如有需要编译器会在最末一个成员之后加上填充字节（trailing padding）。

    对于上面的准则，有几点需要说明：
1) 前面不是说结构体成员的地址是其大小的整数倍，怎么又说到偏移量了呢？

因为有了第1点存在，所以我们就可以只考虑成员的偏移量，这样思考起来简单。想想为什么。

结构体某个成员相对于结构体首地址的偏移量可以通过宏offsetof()来获得，这个宏也在stddef.h中定义，如下：

#define offsetof(s,m) (size_t)&(((s *)0)->m)

例如，想要获得S2中c的偏移量，方法为

size_t pos = offsetof(S2, c);// pos等于4

2) 基本类型是指前面提到的像char、short、int、float、double这样的内置数据类型。这里所说的“数据宽度”就是指其sizeof的大小。由于结构体的成员可以是复合类型，比如另外一个结构体，所以在寻找最宽基本类型成员时，应当包括复合类型成员的子成员，而不是把复合成员看成是一个整体。但在确定复合类型成员的偏移位置时则是将复合类型作为整体看待。

这里叙述起来有点拗口，思考起来也有点挠头，还是让我们看看例子吧（具体数值仍以VC6为例，以后不再说明）：

struct S3
{
    char c1;
    S1 s;
    char c2;
};

S1的最宽简单成员的类型为int，S3在考虑最宽简单类型成员时是将S1“打散”看的，所以S3的最宽简单类型为int。这样，通过S3定义的变量，其存储空间首地址需要被4整除，整个sizeof(S3)的值也应该被4整除。

c1的偏移量为0，s的偏移量呢？这时s是一个整体，它作为结构体变量也满足前面三个准则，所以其大小为8，偏移量为4，c1与s之间便需要3个填充字节，而c2与s之间就不需要了，所以c2的偏移量为12，算上c2的大小为13，13是不能被4整除的，这样末尾还得补上3个填充字节。最后得到sizeof(S3)的值为16。

    通过上面的叙述，我们可以得到一个公式：
    结构体的大小等于最后一个成员的偏移量加上其大小再加上末尾的填充字节数目，即：

sizeof( struct ) = offsetof( last item ) + sizeof( last item ) + sizeof( trailing padding )

辛辛苦苦,过舒服日子;
舒舒服服,过辛苦日子!