先介绍一下我们这个项目：是将open source的一个实现拿到自己的产品当中（当然license
上是没问题的）。主要的工作是移植+少量的升级，原来的实现只支持主流的Intel平台，我
们要将这个东西移植到12个平台，而且我们已经有了一套port层的API，也就是说我们只需要
将所有涉及到和平台相关的代码全部替换成port层中对应的API。原来的实现层次上也很清
晰，大部分都是相同的代码，少数不同的地方也都放在了不同的文件。看起来是个非常简单
的项目，那么我们就来看看这样一个简单的项目是如何失败。

一共4个人投入这个项目，计划两个人做升级，两个人做移植，我被分去做移植。

问题一

四个人都是做java的，只有一个在项目中使用C/C++，其他人都只停留在学校作业的水平

如果从上面的需求看，这样的状况完全是可以接受的。只要理解了框架，在合适的位置加点
代码就可以了，已有的代码也是个很好的参照；移植基本就是个体力活，仔细不出错就没问
题了。事实证明，对于不熟悉的语言，解决问题的效率明显下降，很多我们折腾了几天了的
问题，有经验的人可能一分钟就能搞定。不过项目组里在实在是没有其他人了，这个风险应
该是已经计算在内了。但是许多小问题堆积起来有可能就是致命的，这只能算是其中的一个
了。

问题二

没有及时的与其他模块集成

我们这个号称敏捷的team在这一点上连敏捷最基本的尽早集成，持续集成都没有做到，汗颜
啊。我们只是在自己的小作坊里拼命的搞呀搞，最后发现我们的东西拿给integration team
根本就没法build，然后花了大量的时间来解决在各个平台上的build问题。这时问题一就凸
显出来了，面对不熟悉的语言，不熟悉的工具，完全陌生的平台，写脚本去build一个复杂
的工程（原来用的都是已有的东西）。由于build的问题迟迟没能解决，导致后面测试和我
们fix bug的时间非常有限。

问题三

不求甚解

就我来说，我做完移植后都不知道整个模块的运行机制，工作原理，只是一个API翻译的码
工。其他人也都差不多，对整体的构架和大致的流程都不是很清楚。不过我们这群人还是很
强的，都是fix bug的高手，每天维护这大量完全不熟悉的代码，即使不懂，不太懂照样游
刃有余。这里的问题是我们没有责任感，为移植而移植，为升级而升级，完全不去试图理解
自己所在做的事情，殊不知，这些拿进产品的代码最终还是要我们自己来维护的啊。这种情
况一直到项目的最后期才有所好转，修了那么多bug，再不熟都说不过去了。但这种从局部
一点点的理解不仅效率低下，而且始终对代码没有充分的自信。即使现在我们也不敢对已有
的代码做大的改动，因为我们完全不知道在这里的修改是否会影响的其他部分。

我觉得在项目刚开始应该首先学习已有的代码，顺便温习C/C++的知识，对项目整体的了解
是必要的，也是最基本的。

问题四

对风险估计不足

细心的读者可能已经发现了，我们前面项目的概述中有两个重要的风险没有考虑到：已有代
码中的bug和我们依赖的port API的bug，我们都假设它们是不存在的！！就是这两个东西让
我们陷入了泥沼无法自拔。客观的说从open source拿的代码质量还是非常高的，而且有一
个完整的测试框架和大量的自动化测试用例，但要作为产品，显然还需要锤炼。port API的
问题相对少一些，但很难发现，而且一旦出问题修正的周期非常长，无疑对我们的进度会有
很大的影响。

刚过了TCK我们说，TCK都过了，应该没啥问题了，可是SVT报过来一堆bug，我们恍然，SVT比
TCK牛多了，真是什么bt的测试都有。等SVT都过了，突然冒出个RAD，一下就是十几个bug，
还发现一个spec没实现，一问结果人家是人肉测试 -_-!!
做最好的希望，做最坏的打算任何时候都是适用的

问题五

兵力分散

上一条对这个有直接的影响，也跟我们team人太少有关。项目中的4个人只有一个人是绝大
部分时间在这上面，其他人是需要了再过来，搞着jdwp还要搞其他的东西，严重分散了精力。
期间由于没赶上SR2，中间有一段相对空闲的时间，大部分人都被抽取干其他的任务，默认
是不会再有什么问题了。。。这实际上是我们team一直存在的问题，一人多职，每个人都没
法专注在一件事上，造成每件事都效率不高。

问题六

反馈迟缓

敏捷啊，又犯了敏捷的大忌。从项目开始的头几个月我们没有试图去获得或者争取任何反
馈，直到测试组参与进来。即使我们能够获得完整的SVT测试用例我们也没有尝试主动去获取
反馈（跑SVT测试），我们始终都是被动的。我们虽然没办法让客户尝试还没正式发布的版
本，但至少我们自己可以，在team内部使用还是没什么问题的。jdwp大家平时调程序都会用
到，如果我们自己使用的话，很多显而易见的bug就不会到最后才被发现。虽然作为SDK本事
不稳定会影响大家开发的效率，但能及时发现问题，将其扼杀在摇篮中，我认为还是非常值
得的。

问题七

基础设施（Infrastructure）不健全

我们的code repository还是不能不说的。为什么会变成这样我也不太清楚，总之它现在的情
况是这样的：我们有自己的code repository A，每次做integration build，我们会把当前
最新的代码发布到另一个repository B，这个B不仅包括了我们jdwp的代码，还有其他我们放
进产品的代码，integration build会从这里拿代码去build。注意这里的发布其实就是复制
A里的文件到B并且修改所有文件头的日期信息，这个动作是由脚本完成的，commit的注释就
是load module balabala之类没啥意义的东西，如果用svn diff看某个版本的修改，你会看
到所有的文件都被修改了，绝大部分仅仅是文件头被改了。看官可能要骂了，不就是个用来
做integration build的临时库嘛，讲这么多干嘛，其实我们的项目只能在这个临时库
build，因为修改过的脚本都在这里。各位现在能理解我们的痛苦了吗？我们必须在B上开
发，而B除了做更新外没有任何用处，如果要查看历史，请去A，要提交修改，对不起请去A，
我在B上开发竟然要去A上提交！！！就这样来回的折腾啊，我们的时间就这样消耗啊。。。

这样看来整个项目真是一团糟，但我们竟然真的把它放进SR3了，当然还会有
SR4，5，6，7。。。为了不让惨剧继续上演还有很多需要做：

1. 修改 repository A 上的build脚本，以后直接在A上工作

2. clean 测试用例，补充测试用例，这是保证质量的第一关。

3. 组织一次组内sharing，share项目的整体构架，运行机制，常见工具的使用，常用的解
决问题的方式，将其记录在wiki上。

4. 号召大家在日常工作中使用自己开发的工具，小白鼠从自己做起。

The fundamental problem of RPC, which is trying to make remote calls look local, is based on essentially trying to ignore the problems covered by the fallacies or trying to pretend they don't even exist



严重同意，理由如下：



Network partitions are real, timeouts are real, remote host and service

crashes are real, the need for piecemeal system upgrade and handling

version differences between systems is real, etc. The distributed

systems programmer *must* deal with these and other issues because

they affect different applications very differently.



这一点非常赞同，也深有同感。在做FileServer的时候所有的节点都是通过RMI进行通讯，最初使用RMI的目的就是

简化网络部分的开发，对于一般的开发人员无须理解RMI，动态代理，只需要像使用本地方法一样就可以访问远程

节点。这种方案确实很好的隐藏了网络细节，使网络对开发人员完全透明，但有个问题始终无法很好的处理：异常。

网络错误是随时都有可能发生的，对于不同的错误需要根据环境和需要做具体的处理，比如，多试几次，尝试下一个

节点，对于无法处理的还可以直接抛出。而这种策略的选择和使用必须由应用逻辑层完成，可是应用层假设是不知道

网络存在的，它甚至无法知道自己调用的方法中哪个是远程调用，哪个是本地调用。这种矛盾从根本上说明了网络的

复杂性和多样性是开发分布式应用的程序员必须面对的，是逃不掉的，要直面这惨淡的人生T_T



下面阐述了使用类型系统的缺陷：

Such systems also have problems with impedance mismatch between the

IDL and whatever languages you're translating it to. If the IDL is

minimal so that it can be used with a wide variety of programming

languages, it means advanced features of well-stocked languages like

Java and C++ can't be used. OTOH if you make the IDL more powerful so

that it's closer to such languages, then translating it to C or other

more basic languages becomes quite difficult.

On top of all that, no matter how you design the IDL type system, all 

the types won't -- indeed, can't -- map cleanly into every desired 

programming language.



类型系统一直都在进化，从弱到强到动态，你相信会有一种类型系统可以和所有

的其他语言进行完美的映射吗？如果真存在，类型系统的进化就毫无意义了。定义

一个新的语言，然后映射到其他语言，最后号称“我是跨语言跨平台的！”，这种

解决问题的方式根本就是有问题的。WSDL使用XML描述，有着更好的可扩展性，只是

酒瓶换新酒，根烂了，再换也没用。



Ultimately, RPC is a leaky abstraction. It can't hide what it tries to

hide, and because of that, it can easily make the overall problem more

difficult to deal with by adding a lot of accidental complexity.



下面对为什么 message queuing system 适合分布式系统做了很好的总结：

Message queuing systems work well because (in no particular

order):



* they don't pretend to be programming language procedure or method

calls, so they avoid the associated impedance mismatch problems

* they don't try to hide distributed systems issues

* coupling is low -- drop a message into a queue here, pick up a

message from a queue there

* queues can be persistent, or more generally, delivery guarantees can

be varied as needed

* asynchrony

* payloads need not conform to some made-up IDL type system

* getting two different messaging systems to interoperate is easier

than getting two different RPC or distributed object systems to

interoperate