19.
已经实现了exception的stack track，现在的问题是考虑当stack在不同的system boundary之间传递的约束。
18.
接问题17，恼人的异常，我前面的设计遇到的问题是：逻辑几乎完全相同，但是需要同时兼顾CORBA, EJB, WebServices的远程调用能够抛出的不同异常，为了避免类污染和classpath污染，我的做法是一个base项目，另外3个Abstract子项目分别处理这三种不同的client的异常，包装成base项目里面的自定义异常，不知道还有没有更高明的办法？
顺便提一下：EJB时代有人提出一种巧妙的设计，就是先设计Service Interface接口，然后让EJB的remote和local接口都继承自这个Interface，这样可以达到的效果是远程调用和本地调用可以灵活的切换，但是我认为这个是一个反模式。由于Java不允许子类抛出父类没有抛出的异常，所以在定义的Interface里面必须抛出RemoteException，否则EJB的remote接口不可以继承该自定义接口，这样带来的问题就是接口污染、类污染，如果子类抛RuntimeException，又会给Container带来很大困惑。况且提不提供远程调用本身我认为就是在Design阶段应该仔细考虑的问题。
17.
接问题16，异常类和类型的定义大致采取什么分析方法？我觉得比较normal的做法是采取Brain Storm方法，罗列所有可能出现的异常，然后归类，整理，提取，抽象。
16.
在大型项目大exception设计中，关于exception的描述应该放在哪里？DB还是配置文件？如果放在DB是最方便也是最容易维护的，但是存在的问题是当DB发生故障的时候就意味着客户可能看不到这些信息；如果放配置文件，国际化就要分散在DB和配置文件，而且维护也是两种存取风格。继续考虑ing。。。
15.
考虑以下问题：
为什么需要Daily Build？Daily Build的目标和输出是什么？持续集成又能达到一个什么效果？Daily Build和持续集成对变化和规程有什么限制？
编译通过的单元但是功能不通过的单元，是否允许提交, etc？
14.
项目的文档管理和source的change和版本管理的document话，还是比较麻烦的。不知道老段哪里有没有现成的军规？！
13.
SharePoint管理项目和文档，投入力度也是比较大的。
12.
Portal, 现在公司的Protal基本实现了单点登陆，小地方还需要改进一下。
11.
Enterprise Directory:
所有的员工信息维护在这一“个”LDAP服务器里面，有多个LDAP服务器组成全局系统，同步需要大约两个小时。Outlook里面的通信录所需字段也直接从这里面取出来。
10.
现在项目的版本管理采取CVS。
问题：普通用户不能删除CVS上的目录，如果要删除目录必须具备PL或者SCM Owner的角色。
问题：CVS的delete file，有两种方式，自己做的，不能保留历史信息，但是可以ask for CVS Admin, 他可 以 帮你rename，而且还保留历史信息。
处理：如果用户需要删除CVS上的目录，可以用自己的CVS账号登陆Portal上的MySCM模块，提交删除申请和理由。同时在这里面可以看到自己的账号属于那些项目等等信息，也可以request一个新的项目(request表单里面提交需要使用的是CVS还是Clearcase，PL是谁，SCM Owner是谁， Project Name, Module Name, Team Member等等)，如果拥有足够权限可以增加别人到自己的项目里面来，可以进行授权等等。同时在这里可以设置是否强制commit时必须填写comments，是否进行Java Style Check，是否进行文件名check，项目目录结构模板，文件名称模板等等。
想看看CVS Admin的管理界面了T_T
CVS 的Undelete怎么做？
0. 等PM从美国回来，跟他讨论一下几个问题：
1.
Knowledge Sharing:
现在做的东西很多是以task形式出现，不是每个人都需要参与，这样下来的话形成几个不好的地方，举个例子：如果一个task是给我的，在指派这个任务给我的时候，客户或者PM告诉我怎么处理这个task，参考文档在哪里，如果我突然有事情不能来公司，那么这个工作方面就很困难，受制于几点，客户给的文档不一定是完全正确的，自己做过一遍可能知道什么地方需要修改，这样移交或者突发性时间就会带来重复培训的影响（不仅如此，自己做过的如果没有随手记录一下的习惯下次就会漏掉一些步骤，而客户的文档通常不会允许你直接修改，因为各种原因限制，也有可能是他会觉得就这么一个task，没有必要给你讲一堆他的环境的东西），我现在一个想法是弄个系统，类似BBS，名字可以叫knowledge share for Project XXX，我做完这个之后直接把我的一些步骤和截图给post到这里，然后PM或者有权限的人经过整理可以重新归类归档，问题是还没摸清楚如何跟组织上面的系统挂接。Email来track始终不如db支持的彻底。另外一个需要讨论的问题是没准就需要要从这个系统里面很容易生成word文档或者其他格式来递交给客户。
同样道理，如果我的task做好了，可以去看看其他人做的什么task，都是怎么做的，嘿嘿。（这里可能有点可以改进的是，如果post的程序越容易大家的积极性就会越高，所以应该可以随便post，然后PM或者对应的人来归类：归类需要对项目的整体把握比较多，PM或者PL承担这个工作最适合了，嘿嘿）
2.
如果有了DB，最好就是把这个前端给用起来，打造一个自由的积极的内部交流环境，设立灌水和好文好书推荐和心得推荐分板块，作为财富积累下来，同时有助于团队向心力的建设。
3.
感觉项目meeting的效果不是很好，非正式的观点容易丢失，谈话没有记录，不如弄个wiki之类的可以自由post的系统试试看？不过问题同样在于”项目特色化“和”组织的监管力度“之间的沟通成本。另外这个系统不应该post结束就好了，这是一个basic的功能，应该有很强的后期处理功能，比如归类，起新帖讨论（但是不能丢失路径，这个讨论路径一定要跟踪下来，不知道能不能算是branch），flag等。跟老段讨论了一下这个部分，觉得利用业余时间尝试一下jspwiki，如果可行推广一下，感觉的出老段这个部分的心得非常多，估计我有的玩了，首先熟悉工具，然后就是最重要的部分，如何利用这个工具来把流程玩转。比如老段提到过：客户不能直接修改，只能使用注释语法，非常amazing的一种管理方式，我喜欢。
这个话题我会不断回来补充和修正，谢谢老段这盏灯塔的力量，收藏一下几个link：
http://blog.donews.com/skyhero/archive/2004/12/12/201079.aspx
http://blog.donews.com/skyhero/archive/2005/06/24/443208.aspx
http://blog.donews.com/skyhero/archive/2005/10/23/599310.aspx
http://www.writely.com/
http://www.jspwiki.org/
http://www.xwiki.org/
4.
有关过程改进：
一般公司的工作计划都是比较满，同时由于人类认知的共性，不可能一次性考虑清楚所有的问题，这样在实际运作过程中暴露出来的一些问题就需要按照一个流程进行描述，提交，由PM进行归类，暂时不需要action的，需要单独归到另外一个板块或则类别，等项目的淡季周期性的回顾，迭代式处理，这样子下一个项目可能就会当中受益。
5
发现sharepoint也很牛
6.
最关键的还是一个团队气氛问题以及整体之间的互相信任问题。
7.
任何项目的最佳建议和实践都是单独创建一个SandBox的环境，给member练习各种东西，可以随时重建，比如wiki中的sandbox的功能就不错。不要小看这个带来的力量，可以让members自由练习而不必担心弄坏环境。
8.
对于项目中还要兼容历史遗留系统的新功能开发，一定要严格把关，这次我的设计就差点。幸亏我采取的是最小影响法，只要够用，就没有引入过多的第三方类库，否则改成JDK1.3来编译可就叫后悔莫及。
9.
听君一席话，老段。有个好的气氛，如果再有一个好的Mentor，那就在好不过了，否则光是气氛好，虽然可以实现那些目标，终会走一些弯路，“浪费”那么一点点儿的时间。。。。
