电文处理任务结束会

1.内部review很重要！

 

以PD书内外review为例（此处的”内“指的是将式样书发给日方客户前，项目组内部leader或者较高级别的同事对式样书的检查，尽量找出问题并让担当者修改掉，尽量将较高质量的设计文档提交给日方客户；”外“指的是日方客户对我方提供的式样书的检查，待客户通过后，再交给我方进行具体实施）（20090414追加）。

PD书（程序设计书），界于DD书（详细设计书）和code（编码）之间。
平均下来，我方认真review和大致review（说得直白点，大致review就是没怎么看，眼睛扫描了几下，找出了几个最明显的错误，此种情况一般出现在时间不够的情况下）之后，日方客户再review出的问题数，对比结果是：10：40，中间相差30个问题，差距还是很明显的。极端情况，客户对某个PD书指出了73个问题。

2.在日方客户提供的BPM（bug管理系统）上填写bug信息时，bug原因一栏应该只填写一项。

出现的问题：填了3项，导致bug出现原因统计时会有误差。

3.bug原因统计饼图中，跟式样相关（式样遗漏、式样理解不足、式样确认不足）的bug占了bug总数的一半左右 。

（20090414追加）该统计结果和实际现象比较吻合，这可能也是中日文化差异导致的必然结果。这个统计结果也给我方敲了一个警钟：以后，式样的理解一定要更加仔细些，感觉疑惑的、不理解的、不确认的，一定要立马提出来（QA），尽量不要自己YY。

4.部分设计书中没有详细描述，导致式样理解产生困难。

5．修改既存代码时，对既存代码调查不足（没有真正搞清楚这段代码是干嘛的，有哪些注意点等等）。

6.手机模拟器具有差异性，导致相同的代码，测试出来的效果却不一样。

7.特殊字符（比如＠、大小横线等等）的乱码问题 （NBS项目中，邮件内容就出现在过这种问题）。

8．追加机能的式样书，和既存代码有矛盾。

9.有两个案件，PT测试发现的bug数，反而比SI还要多，这是不正常的。

正常情况下，从UT到SI，再到PT，测试发现的bug数应该是正常收敛的（越来越少）。

10．式样变更太多，甚至到了测试阶段还有变更。

->这个问题，可能是对日项目的通病，我参与过的几个项目中，都存在这样的问题。（20090506追加）

11.半角和全角，在页面上的显示效果不一样，也需要注意（日本人对这方面相当仔细和敏感）。

-》做电文处理任务时，在携带部分，也出现过这个问题。（20090506追加）

12.是从内存中，还是从DB中，取数据。处理不好，会存在数据不一致的情况。

13.优点1：天天和日方客户进行电视会议，QA能及时得到正确回复。

14.优点2：BES回上海，及时解决了很多式样问题。

15.一个bug对应完之后，没有认真确认（没有横向展开（相类似的页面）和纵向展开（其他调用这段代码的地方）），导致产生新的问题。 对于这种问题，日方客户比较反感。

16.（测试）式样书的客户review，花费了太多时间，将项目进度拖慢了，成了项目开发进度中的一个瓶颈。

17.发包方和承包方的代码结构不一致，这是日方客户的问题，没有管理好。代码版本也出现过不一致，导致一个“bug”的产生。

18.进行UT时，多人同时修改数据库中的数据（造数据），有时相互之间产生了影响，应该进行更好的管理：比如分测试时间段、或者分配一下竞轮场（或者比赛场次）。

19. 代码版本管理工具VSS关联之后，不能取最新代码，这一点没有SVN强。

20．JSP文件中，使用到了<!-- -->注释，这种注释在PC上没有问题。但是，对于携带（手机）用户而言，这种注释就有问题了，因为是客户端注释，会同时发到客户的携带终端上，无形之中，增加了客户的流量，产生了额外的费用，这是不合理的。

解决方案：全部替换成<%-- --%>服务器端注释。

-》日方客户很重视这个问题，要求我们将其解决掉。可以看出，日方客户确实是为他们的客户考虑，考虑得很仔细很周到。（20090506追加）