BlogJava-狂奔 lion-随笔分类-Other Tech

关于ThreadLocal的内存泄露

杨一 — Fri, 02 Jul 2010 10:27:00 GMT

ThreadLocal是一种confinement，confinement和local及immutable都是线程安全的（如果JVM可信的话）。因为对每个线程和value之间存在hash表，而线程数量未知，从表象来看ThreadLocal会存在内存泄露，读了代码，发现实际上也可能会内存泄露。

事实上每个Thread实例都具备一个ThreadLocal的map，以ThreadLocal Instance为key，以绑定的Object为Value。而这个map不是普通的map，它是在ThreadLocal中定义的，它和普通map的最大区别就是它的Entry是针对ThreadLocal弱引用的，即当外部ThreadLocal引用为空时，map就可以把ThreadLocal交给GC回收，从而得到一个null的key。

这个threadlocal内部的map在Thread实例内部维护了ThreadLocal Instance和bind value之间的关系，这个map有threshold，当超过threshold时，map会首先检查内部的ThreadLocal（前文说过，map是弱引用可以释放）是否为null，如果存在null，那么释放引用给gc，这样保留了位置给新的线程。如果不存在slate threadlocal，那么double threshold。除此之外，还有两个机会释放掉已经废弃的threadlocal占用的内存，一是当hash算法得到的table index刚好是一个null key的threadlocal时，直接用新的threadlocal替换掉已经废弃的。另外每次在map中新建一个entry时（即没有和用过的或未清理的entry命中时），会调用cleanSomeSlots来遍历清理空间。此外，当Thread本身销毁时，这个map也一定被销毁了（map在Thread之内），这样内部所有绑定到该线程的ThreadLocal的Object Value因为没有引用继续保持，所以被销毁。

从上可以看出Java已经充分考虑了时间和空间的权衡，但是因为置为null的threadlocal对应的Object Value无法及时回收。map只有到达threshold时或添加entry时才做检查，不似gc是定时检查，不过我们可以手工轮询检查，显式调用map的remove方法，及时的清理废弃的threadlocal内存。需要说明的是，只要不往不用的threadlocal中放入大量数据，问题不大，毕竟还有回收的机制。

综上，废弃threadlocal占用的内存会在3中情况下清理：
1 thread结束，那么与之相关的threadlocal value会被清理
2 GC后，thread.threadlocals(map) threshold超过最大值时，会清理
3 GC后，thread.threadlocals(map) 添加新的Entry时，hash算法没有命中既有Entry时，会清理

那么何时会“内存泄露”?当Thread长时间不结束，存在大量废弃的ThreadLocal，而又不再添加新的ThreadLocal（或新添加的ThreadLocal恰好和一个废弃ThreadLocal在map中命中）时。

杨一 2010-07-02 18:27 发表评论

关于软件文档，我的看法

杨一 — Tue, 29 Jun 2010 10:26:00 GMT

文档应该包括两大部分，一部分是清晰的代码结构和注释，比如Concurrent API就是这样，还有一部分是文字文档，包括三个小部分：一是开发文档，应该讲架构和功能；二是索引文档，详细介绍功能和参数，三是用户文档，包括安装和使用说明

文档最困难的莫过于版本的一致性，当软件升级后，一些obsolete的内容和新的feature很难同步。要是架构发生了变化，那就更困难了。一般document team都不是太精于技术，所以也会产生一些问题。

只能说任何事物永远都有改进的空间，但是同样也永远没有达到完美的程度

杨一 2010-06-29 18:26 发表评论

多线程的知识

杨一 — Fri, 25 Jun 2010 11:17:00 GMT

多线程的优点：
1 多核利用
2 为单个任务建模方便
3 异步处理不同事件，不必盲等
4 现代的UI也需要它
风险：
1 同步变量易错误
2 因资源限制导致线程活跃性问题
3 因2导致的性能问题
用途：
框架，UI，Backend
线程安全的本质是什么：
并非是线程和锁，这些只是基础结构，本质是如何控制共享变量访问的状态
什么是线程安全：
就是线程之间的执行还没有发生错误，就是没有发生意外
一个线程安全的类本身封装了对类内部方法和变量的异步请求，调用方无需考虑线程安全问题
无状态的变量总是线程安全的
原子性：
完整执行的单元，如不加锁控制，则会发生竞态条件，如不加锁的懒汉单例模式，或者复合操作。
锁，内在锁，重入：
利用synchronized关键字控制访问单元，同一线程可以重入锁内部，避免了面向对象产生的问题。同一变量的所有出现场合应该使用同一个锁来控制。synchronized(lock)。
即使所有方法都用synchronized控制也不能保证线程安全，它可能在调用时编程复合操作。
活跃性和性能问题：
过大的粒度会导致这个问题，用锁进行异步控制，导致了线程的顺序执行。
简单和性能是一对矛盾，需要适当的取舍。不能在没有考虑成熟的情况下，为了性能去牺牲简洁性。
要尽量避免耗时操作，IO和网络操作中使用锁

杨一 2010-06-25 19:17 发表评论

Ext Store Filter的实现和问题

杨一 — Fri, 25 Jun 2010 11:16:00 GMT

Store包含两个数据缓存 - snapshot和data，grid，combo等控件的显示全部基于data，而snapshot是数据的完整缓存，当首次应用过滤器时，snapshot从data中备份数据，当应用过滤器时，filter从snapshot获取一份完整的数据，并在其中进行过滤，过滤后的结果形成了data并传递给展示，及data总是过滤后的数据，而snapshot总是完整的数据，不过看名字让人误以为它们的作用正好相反。
相应地，当进行store的增删改时，要同时维护两个缓存。
问题
Store包含两个增加Record的方法，即insert和add，其中的insert没有更新snapshot所以当重新应用filter时，即data被重新定义时，在data中使用insert新增的记录是无效的。
解决方法
用add不要用insert，如果用insert，记得把数据写进snapshot: store.snapshot.addAll(records)

杨一 2010-06-25 19:16 发表评论

Ext中Combo组件的联动封装

杨一 — Fri, 25 Jun 2010 11:14:00 GMT

摘要: 在Extjs中构造N级联动下拉的麻烦不少，需定制下拉数据并设定响应事件。通过对Combo集合的封装，无需自己配置Combo，只需设定数据和关联层级，即可自动构造出一组支持正向和逆向过滤的联动下拉并获取其中某一个的实例。如：数据： Ext.test = {}; Ext.test.lcbdata&nb... 阅读全文

杨一 2010-06-25 19:14 发表评论

前端框架动态组件和代码生成之间的选择

杨一 — Fri, 25 Jun 2010 11:11:00 GMT

目前主流的SSH开发架构中，为减轻开发者工作，便于管理开发过程，往往用到一些公共代码和组件，或者采用了基于模版的代码生成机制，对于后台的DAO，Service等因为架构决定，代码生成必不可少，但是在前端页面的实现上，却可以有两种不同的思路，一种是把配置信息直接封装成更高级别的组建，一种是进行代码生成。请大家讨论一下这两种方案的优劣，这里先抛砖引玉了。

相同点：
配置信息：XML OR 数据库

控件化：
优点：
1 易于添加公共功能
2 修改配置数据直接生效
3 代码结构清晰，对开发者友好
缺点：
1 重组内存中对象结构，性能没有代码生成好（但渲染时间相同）
2 仅能控制组件自身封装的配置，不支持个性化修改，如果配置文件不支持的参数，则控件不支持
3 必须保证每个控件一个配置

代码生成：
优点：
1 性能较好
2 易于定制内容
3 可以只配置一个模版，然后做出多个简单的修改
缺点：
1 不能针对多个页面同时添加公共功能
2 业务修改需要重新生成代码
3 开发者需要修改自动生成的代码，并需要了解一些底层的实现结构

=====================20091029
代码生成并不能提高工作效率，尤其是针对复杂的富客户端开发
开发组件可提提供一种有效的选项，但是在运行效率和内存处理上需要细心处理

杨一 2010-06-25 19:11 发表评论

Javascript工作流引擎代码及实例

杨一 — Fri, 06 Mar 2009 09:39:00 GMT

最近在学习jBPM和Javascript，所以按照一些相关概念自己写了下面的200行代码的“工作流引擎”，工作流管理系统包含了流程定义，引擎，及应用系统三个主要部分，下面的代码实现了流程的分支合并，目前只支持一种环节上的迁移。拷贝到html，双击就可以跑起来。

//////////定义引擎////////////

Yi = {};
Yi.Utils = {};
Yi.Utils.execute = function(o){
         if(typeof o != 'function')
                   eval(o)();
         else
                   o();
}
//工作流类
Yi.Workflow = function(workflowDef){
         this.def = workflowDef;
         this.tasks = this.def.tasks;
}
//public按照环节id查找查找
Yi.Workflow.prototype.findTask = function(taskId){
         for(var i=0;i<this.tasks.length;i++){
                   if(this.tasks[i].id == taskId)
                            return this.tasks[i];
         }
}
//public启动工作流
Yi.Workflow.prototype.start = function(){
         this.currentTasks = [];
         Yi.Utils.execute(this.def.start.fn);
         for(var i=0;i<this.def.start.next.length;i++){
                   this.currentTasks[i] = this.findTask(this.def.start.next[i]);
                   Yi.Utils.execute(this.currentTasks[i].before);
         }
}
//private
Yi.Workflow.prototype.findCurrentTaskById = function(taskId){
         for(var i=0;i<this.currentTasks.length;i++){
                   if(this.currentTasks[i].id == taskId)
                            return this.currentTasks[i];
         }
         return null;
}
//private
Yi.Workflow.prototype.removeFromCurrentTasks = function(task){
         var temp = [];
         for(var i=0;i<this.currentTasks.length;i++){
                   if(!(this.currentTasks[i] == task))
                            temp.push(this.currentTasks[i]);
         }
         this.currentTasks = temp;
         temp = null;
}
//public触发当前环节
Yi.Workflow.prototype.signal = function(taskId){
         //只处理当前活动环节
         var task = this.findCurrentTaskById(taskId);
         if(task == null){
                   alert("工作流未流转到此环节!");
                   return;
         }
         //对于合并的处理
         if(task.merge != undefined){
                   if(task.merge != 0){
                            alert("工作流流转条件不充分!");
                            return;
                   }else{
                            Yi.Utils.execute(task.before);
                   }
         }
         //触发当前环节
         Yi.Utils.execute(task.fn);
         //触发后动作
         Yi.Utils.execute(task.after);
         //下一步如果工作流结束
         if(task.next === "EOWF"){
                   Yi.Utils.execute(this.def.end);
                   delete this.currentTasks;
                   return;
         }
         //遍历下一步环节
         this.removeFromCurrentTasks(task);
         for(var i=0;i<task.next.length;i++){
                   var tempTask = this.findTask(task.next[i]);
                   if(!tempTask.inCurrentTasks)
                            this.currentTasks.push(tempTask);
                   if(tempTask.merge != undefined){
                            tempTask.merge--;
                            tempTask.inCurrentTasks = true;
                   }
                   else
                            Yi.Utils.execute(tempTask.before);
         }
}
//public获取当前的活动环节
Yi.Workflow.prototype.getCurrentTasks = function(){
         return this.currentTasks;
}
//public获取流程定义
Yi.Workflow.prototype.getDef = function(){
         return this.def;
}

////////应用系统///////////////
var wf = new Yi.Workflow(workflowDef);
alert("启动工作流");
wf.start();
alert("尝试手工执行任务3,返回工作流没有流转到这里");
wf.signal("task3");
alert("分支开始");
alert("手工执行任务1");
wf.signal("task1");
alert("手工执行任务2");
wf.signal("task2");
alert("手工执行任务4");
wf.signal("task4");
alert("手工执行任务5");
wf.signal("task5");
alert("手工执行任务3");
wf.signal("task3");
function begin(){
alert("流程开始，该函数在外部定义");
}
function end(){
alert("流程结束");
}

杨一 2009-03-06 17:39 发表评论

实现Ext表单对checkBoxGroup的统一管理

杨一 — Wed, 04 Mar 2009 04:50:00 GMT

1 对于类型是checkboxgroup的数据，数据库中保存数据的格式是value1,value2...valueN，其中1~N的数据有可能不存在，如果选中则存在，最后拼接成一个串。
在Ext中，通过Record对象向FormPanel中的内置对象BasicForm加载数据时，采用的是setValues方法，而setValues第一步要通过Record中定义的name使用findField方法找到表单元素，遗憾的是，继承了Field的checkboxgroup组件并不能正确的通过getName返回自身引用，所以，需要对getName方法进行重写，此外，为了适应我们采用的数据格式，对于该组件的setValue（被setValues调用）和getValue（获取到已加工的数据，此事后话）也要进行重写。故而对于形如：

{
   xtype: 'checkboxgroup',
   name: 'biztype',
   width: 220,
   columns: 3,
   fieldLabel: '业务类别',
   items: [
       {boxLabel: '类别1', inputValue: '01'},
       {boxLabel: '类别2', inputValue: '02'},
       {boxLabel: '类别3', inputValue: '03'},
       {boxLabel: '类别4', inputValue: '04'}
       ]
}

的checkboxgroup定义，需重写类如下：

Ext.override(Ext.form.CheckboxGroup,{
    //在inputValue中找到定义的内容后，设置到items里的各个checkbox中
    setValue : function(value){
        this.items.each(function(f){
            if(value.indexOf(f.inputValue) != -1){
                f.setValue(true);
            }else{
                f.setValue(false);
            }
        });
    },
    //以value1,value2的形式拼接group内的值
    getValue : function(){
        var re = "";
        this.items.each(function(f){
            if(f.getValue() == true){
                re += f.inputValue + ",";
            }
        });
        return re.substr(0,re.length - 1);
    },
    //在Field类中定义的getName方法不符合CheckBoxGroup中默认的定义，因此需要重写该方法使其可以被BasicForm找到
    getName : function(){
        return this.name;
    }
});

2 通过内置对象basicForm的getValues方法可以获取到一个form的完整json数据，但遗憾的事，这里取到的是dom的raw数据，类似emptyText的数据也会被返回，而Field的getValue方法不存在这个问题，所以如果想要返回一个非raw的json集合，可以给formpanel添加如下方法：

getJsonValue:function(){
    var param = '{';
    this.getForm().items.each(function(f){
        var tmp = '"' + f.getName() + '":"' + f.getValue() + '",';
        param +=  tmp;
    });
    param = param.substr(0,param.length - 1) + '}';
    return param;
}

这个方法同样适用于上面定义的checkboxgroup，如此就可以把前后台的数据通过json统一起来了

杨一 2009-03-04 12:50 发表评论

关于文本协议中二进制到文本的转码

杨一 — Thu, 04 Dec 2008 07:56:00 GMT

偶然间注意到一个困扰了我很久的问题，那就是如果我不通过Socket而通过应用层的某种基于文本的协议，比如SOAP进行通信的话，
如何传递二进制的数据呢？现在SOA，Web Service等很火，应该会遇到这种问题吧？

现在已知的方法可以通过Base64进行编码，其原理和方法见：
http://baike.baidu.com/view/469071.htm

这种方法采用了字节中的6位进行文本转换，并且在其他论坛上也看到了帖子说淘宝的搜索也采用了这种编码方式进行处理。
但是采用了5位进行转换。并且大胆地给出了5位转码的算法，见：
http://www.javaeye.com/topic/286240

不过这种5位的转换会产生更多多余的字节，6位的转码充分利用了现今的可读文本，可是5位却没有，因为5和8的最小公倍数是40，
所以当每转换40位即5个字节的二进制数据需要8个字节来表示，这样就多产生3个字节，浪费的效率是3/5, 而6位转码浪费的效率是
1/3。而且随着字节增多，转化效率也在下降。可见采用5位转码是一种既浪费空间，又浪费效率的解决方案。在不增加url长度的情况下充分提高效率，6位编码是最佳的。如果可以任意的饿牺牲url长度，
可以把0-9全部拿出来当做标记位，0-9不会单独出现，这样一共有10*26 + 26 = 286 种可能还不包括小写字母，
此外还有=，+，-什么的至少256可以编码8位的字节了，这样处理效率就提高了。

现在把问题优化一下，人类可读无歧义的文本码有0-9，A-Z,a-z共62个
设取出x个作为标志位则(62-x) * x + (62 - x) >= 256
解这个二元一次方程得到:
3.366<=X<=57.634
考虑到编码的文本长度，取x的最小值，即 4
最优解：
用0, 1, 2, 3做为标志位
4-9，A-Z, a-z参与编码并与标志位配合实现8位字节的文本化
可以看到这种方法的转码效率会比较高，但是空间冗余大。

此外其实可用的文本不知62个，包括感叹号等用上后补足64 = 2^6
它的高位是 00
那么只要再找到三个文本符保存其他三个高位01 10 11就可以了
这样的转码空间可以更小一些。

想法还很不成熟，欢迎大家批评

杨一 2008-12-04 15:56 发表评论

也谈普元

杨一 — Thu, 04 Sep 2008 07:41:00 GMT

偶然间看到下面有一个网友慨叹普元的强大，而开发人员的渺小。
小弟刚刚参加工作，也在项目中接触到了普元的EOS。普元的这个东西怎么说呢，就是乱用XML然后Spring没做好就变成那个样子的，同时失去了类型的表述，一部机器要进行装配需要组件和零件，软件应该自上而下，分而治之，这是上个世纪70年代，学者们就达成的共识，所以关于“银弹”神话的唯一结论就是——“没有银弹”。
为什么说EOS是没有做好的Spring？
Spring简化了对象的装配，强调重用，是建立在面向对象基础上的，是建立在敏捷测试基础上的，是建立在强类型基础上的；
而EOS则是建立在面向过程的基础上的，建立在不可测试的基础上的，建立在毫无类型基础上的（全是String）
然而EOS也有很多的优点（据小弟不完全发现）：
1）EOS固化的开发流程强制一个team从一种易于维护的结构组织Web，包括页面，表示层，逻辑层等等。否则的话就需要一个架构师来做出规约，但仍不易于管理；
2）EOS的画图功能让人耳目一新，从“代码即文档”的哲学出发，这些画图很好地诠释了代码表述的内容和结构，给程序的维护带来便利。
3）相对于OO和J2EE传统开发，EOS易于上手，学习曲线较短。但是这一点有争议，EOS的知识不具备通用性。
综上，根据2-8的关系法则，在某些领域EOS的确有其优点，但是认为EOS完全“解放”了程序员，则是不负责任的说法。
这只是我的个人看法，欢迎大家就此话题讨论。

杨一 2008-09-04 15:41 发表评论

myeclipse

杨一 — Fri, 28 Dec 2007 03:39:00 GMT

刚看了myeclipse，eclipse是一个很可怕的东西，它试图让所有的开发人员一打开电脑就不能够离开它，还要在里面完成所有的工作。人们不至于反感它的原因是它是开源的，不受商业控制的。如果我们对于myeclipse过度依赖，必然最终走向对微软严重依赖的老路。我不反对利用软件盈利。但是自由的精神不应被改变。
微软和我们是原始的猎人与猎物之间的关系，虎与伥的关系，最终极的占有。我们这才生是MS的人，死是MS的鬼。

杨一 2007-12-28 11:39 发表评论

Are you a coder or a programmer?

杨一 — Wed, 13 Jun 2007 11:47:00 GMT

Are you trying to build software that is composed by software components provided by large companies, and still name it a system?
Are you doing the job anybody can do if given enough time to read the technical handbooks and rebuild the system or you have created something?
If you are in the same situation, you are probably a coder instead of a programmer.

杨一 2007-06-13 19:47 发表评论

My Attitude Toward Linux Shell

杨一 — Thu, 31 May 2007 15:08:00 GMT

I must be an extremely patient user of Linux, for I have been trying to install all versions of Linux distributions lately, and getting used to the shell commands.

I also read some books on the subject. To be honest, it is true that the command lines are more efficient, and this can be verified by the following calculation:

Suppose a mouse have 3 keys, and the keyboard ten times more. The three key mouse can generate actions 3^2 when clicked 2 times, while the keyborad 30^2. Come on, no matter we clicked the keyboard or the mouse, we just clicked 2 times.

杨一 2007-05-31 23:08 发表评论

学习Linux有感

杨一 — Mon, 06 Nov 2006 02:20:00 GMT

记得很久以前，曾经看过一篇帖子说，“完全使用 Linux ，脱离 Windows ”，在最近的一个月时间里，我尝试了这种做法。结论让我不得不说： Linux 如果作为桌面来使用的话，还远远没有到达实用的程度。

作为开发环境和服务器倒是非常不错的，因此我把 Linux 配置成了一个开发工具，而用 Windows 来娱乐。

vi nano emacs anjuta eclipse都是非常好的编辑开发工具。

杨一 2006-11-06 10:20 发表评论

编程的6个原则

杨一 — Fri, 13 Oct 2006 14:03:00 GMT

摘要: 原作：Joseph Ottinger，来自近日的theServerSide，本文是译文。

原作网址：http://www.theserverside.com/news/thread.tss?thread_id=42598

Empathy Box在blog中介绍了编程应该注意的5个问题，这篇文章实际表述了编程时应引起注意的很重要的6个思想阅读全文

杨一 2006-10-13 22:03 发表评论

开源软件优于商业软件吗？

杨一 — Sat, 16 Sep 2006 10:07:00 GMT

摘要: 本文是TheServerSide首页的文章，本文是译文，本文基于一个调查，结合关于开源软件质量的文章，发表了作者关于开源软件质量的一些看法阅读全文

杨一 2006-09-16 18:07 发表评论

关于SOA与Web Services的疑问

杨一 — Fri, 18 Aug 2006 09:51:00 GMT

    今天忽然想到一个问题，Ｗｅｂ　Ｓｅｒｖｉｃｅ未来的发展趋势是什么？为什么近两年听到的声音越来越少了？记得０４年的时候，WS还是比较火的，不仅在课堂上学习，还做过一些ｊａｖａ和.ｎｅｔ的应用，以后就不怎么用了，也许是分布式理论受到了挑战吧（Rod果然站在时代的前沿）。
    许多人说，现在最火的SOA里面用到的技术就是Ｗｅｂ　Ｓｅｒｖｉｃｅ，可是ＳＯＡ是个概念而已，大厂商主导的东西不一定经得起推敲的，正如ＷＳ一样。

网上一篇介绍SOA的文章如是说：

面向服务架构（SOA）的原则

Web service已经不再是新婚的娘子。众多企业都已经创建各种实验性Web Services 项目，事实证明，这项新兴的分布式计算技术确实能够降低集成和开发的成本。另外，一些关键的Web Services标准纷纷制定，强安全（robust security）和管理方面的产品也陆续问世。对于志向远大的企业来说，他们已经在考虑下一步了。

对大多数公司来说，下一步要考虑的不再是点对点的应用，而是Web services在企业间以及业务伙伴间更为宽广的应用。这种技术的变迁需要更松散耦合、面向基于标准的服务的架构。这样一个架构要求对IT在组织中的角色有新的观点和认识，而不仅仅是一种实现方法。通过对业务的敏捷反应，企业可以得到实实在在的回报，而要达到这一点，面向服务架构设计师的角色非常关键。除此之外，潜在的回报更是不可胜数－分布计算技术能够保证对业务需求足够灵活的反应，而这种业务上的敏捷正是各公司梦寐以求而目前还遥不可及的。

分布式计算将网络上分布的软件资源看作是各种服务。面向服务架构是一种不错的解决方案。但这种架构不是什么新思想；CORBA和DCOM就很类似，但是，这些过去的面向服务架构都受到一些难题的困扰：首先，它们是紧密耦合的，这就意味着如分布计算连接的两端都必须遵循同样API的约束。打比方说，如果一个COM对象的代码有了更改，那么访问该对象的代码也必须作出相应更改。其二，这些面向服务架构受到厂商的约束。Microsoft控制DCOM自不必说，CORBA也只是一个伪装的标准化努力，事实上，实现一个CORBA架构，经常都是在某个厂商对规范的实现上进行工作。

Web services是在改进DCOM和CORBA缺点上的努力。今天应用Web services的面向服务架构与过去不同的特点就在于它们是基于标准以及松散耦合的。广泛接受的标准（如XML和SOAP）提供了在各不同厂商解决方案之间的交互性。而松散耦合将分布计算中的参与者隔离开来，交互两边某一方的改动并不会影响到另一方。这两者的结合意味着公司可以实现某些Web services而不用对使用这些Web services的客户端的知识有任何了解。我们将这种基于标准的、松散耦合的面向服务的架构简称为SOA。

    这和当年的宣传WS并没有什么不同，仅仅多了个ＳＯＡ而已，试问今天的架构师，哪位应用了ＷＳ，哪位涉及了ＳＯＡ？有多少成功的案例？哪位知道这项技术在美国的发展情况，有很广泛的应用吗，还是仅限于ＳＯＡ？
    真正项目中需要SOA思想的那种跨国财团有几个？对于在国内最多的中小型应用，暴露服务倒是极危险的事情。不过作为程序员，学习新技术，新概念实属无奈之举。有些不必要的复杂性干扰人的思维，让你无法干净利落地做事。

杨一 2006-08-18 17:51 发表评论

关于敏捷开发的疑问

杨一 — Thu, 17 Aug 2006 04:43:00 GMT

学习了很多人捧为经典的ppp之后，我开始考虑在所参与的团队中采用敏捷开发的方式，除了结对编程，基本采用XP编程的方式。跌代计划，TDD，重构，积极沟通。然而在此过程中却遇到很多尴尬的问题，一个是团队中的人员经常流动，导致刚刚熟悉的开发环境，又要找新人代替；一个是团队中的成员水平参差不齐，难以达成一致的良好设计规范，也许又是不得不做一些硬性的规定。
这里最大的问题是：XP强调代码即设计，那就要求每个人都对代码的编写非常熟练，对团队中每个成员的编程水平要求很高，然而这和相对较少的项目经费，及短暂的项目周期难以协调。
更为可怕的是，项目中的人员职责不明，没有明确的负责人，而由没有软件开发和管理经验的人主导。

杨一 2006-08-17 12:43 发表评论

Google建立与sourceforge, java.net匹敌的开源资源库

杨一 — Thu, 03 Aug 2006 07:05:00 GMT

Google 为开源项目建立起了资源库. 这个google站点是google为推动开源发展做的又一努力！

Google在FAQ上说道, Google意识到对开源项目开发者而言，有多种的选择未尝不是一件好事。这个开源资源库强调软件资源的储存,邮件列表讨论和bug追踪.

需要说明的是google资源对选择了具备一定的合适许可证的知名项目（比如sourceforge上的项目来提供下载）。站点采用SVN进行管理。

您对google的新举动有何高见呢？

杨一 2006-08-03 15:05 发表评论