原创于2008年03月19日,2009年10月18日迁移至此。
上周四上午( 3 月 13 日),一个日本保险业的项目刚刚召开了项目开工会,一共 3 个印度人和 3 个中国人;当天下午一位兄弟便收到了 offer ,发出了离职信;第二天我也收到了电话 offer ,也发出了离职信。项目刚刚启动,便有两个人即将离职了 … 不知道是不是很多项目也有类似的经历。
不得不承认,印度人是挺能忽悠的,说出来的东西都是一套套的,这也许就是所说的 presentation 很强;这只是个评估项目,对现存的业务系统进行业务咨询和技术上的规范和文档化,印度那边居然派来了一个 domain expert 和一个 technique architect ,对他们的真实水平确实不了解;和同事聊起来的时候也提起过,印度人的技术和业务框架完善的程度确实和我们不在一个级别上,但是真正落实到实处,却也未必比中国人更强,我经历的项目也说明了这一点, CMM 流程比较完善,软件工程 却很不规范。这也许就是被我们认为的 CMM 的诟病吧。不过我觉得项目和产品不同,项目更需要对人力、资金、进度进行控制,所以无法完全按照 CMM5 的规范进行,但是版本管理 的规范化、项目进度的监控以及项目事后的度量确实有助于在更大范围对以后公司或部门研发能力进行评估。 CMM 也许更适合于不计成本的产品的研发活动吧。
该项目是日本一个保险公司在上海的分公司,项目建设比较早,从上个九十年代的 foxpro 开始,后来于 02 年左右用 ASP 重新开发过,然后使用到现在,从现在的角度看,当然技术比较陈旧、代码也很不规范、数据库 设计一团糟、业务功能也只是简单的模块化;典型的 ASP+COM++SQLServer 的方式,我很怀疑日本人怎么能这样容忍了好几个年头。和日本人的沟通是用英语的,他们的英语更加像一个字一个字的发音,不过很奇怪他们的听力似乎都不错,头一次遇到印度英语 PK 日本英语,这两种世界上最难的英语,对我来说简直是一种折磨。
要对现有系统进行分析了,其实之前我把拿到的数据库脚本大致看了一下, 400 多个表、 1200 个存储过程,没有任何关系和约束,就算神仙也分析不出来吧;今天上午调通了 VPN 能够通过远程桌面连接进行访问了,不过很奇怪,远程访问中的 web 页面访问有些问题,很多页面无法打开,本来预备的讲解无法继续了;只好申请了一台测试服务器,把从客户现场拷回来的代码恢复 回来,准备在公司搭建一个测试环境。
下午拿到安装了 Windows2003 操作系统的机器后,然后又安装了 IIS 和 SQLServer2003 ,恢复备份 数据库,创建 web 虚拟目录 ,然后注册 COM+ 组件。
以前倒是倒是通过 regsvr32 命令注册过 COM , COM+ 却是不行,在网上搜索了一下,算是学会了。
注册之后,打开 web 页,发现始终访问不了,只能访问目录下的 HTML 文件,始终不能访问 ASP 页面,在权限和 IIS 处折腾了很久,又请了 2 位 .Net 高手来帮忙,还是搞不定,后来我还是在网上搜索了一下,发现 IIS 下面的 ASP+ 被禁用了,呵呵;原来我也是高手啊,或许世上本没有高手,从网上查出来的就是高手。
再次打开 web 页面和 SQLServer 的 profile 对每个页面的处理进行跟踪,一开始发现并没有登陆到数据库中,到 ASP 脚本中发现都是读取该目录下的配置文件,然后修改了一下,运行 OK ;继续进行调试,发现问题越来越多,很多目录下都有相应的配置文件,数据库中也有相应的数据源配置, ASP 包含的资源不能打开,折腾了 2 个多小时,再也折腾不下去了;希望明天找到合适的资源帮我们进行 debug 和分析吧 …
晚上和同事讨论关于分析文档的事,他说很简单的事情被我搞复杂了 L ,要做的事情就是把每个 ASP 页面使用 COM+ 组件、存储过程、表找到就 OK ,这就是分析?我无语了。这就是印度人要求的结果吧,算了,要休息了 J 越来越能发牢骚了,这个习惯可不好。