对日外包总结-泛泛而谈

--以下是收集到的文章，还需要修改和添加自己的经验总结。

以后要多多学习别人的经验

http://kang.javaeye.com/category/38901

内部review很重要！

 

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

--本人注语：review如果遇到不太负责人的同事，一般很难看出较多的业务问题。这样就需要想法子提高review的质量。

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

         ①. 概要设计理解阶段，由担当者、Leader、Tester，甚至包括"业务沟通者"来进行概要设计的共同理解。可以由此产生简单的类图、数据流图（或者是数据CRUD图），理想情况下做出程序的业务Sequence、业务画面的工作流程（遷移）图。

         ②. 详细设计产生第一阶段:生成业务画面的业务设计图，由共通担当(或Coder Leader等)构架共通程式，构架整个项目的结构，构架大致的系统异常和业务异常处理方式等。并根据客户的要求以及编码规范等产生详细设计规范、编码流程规范、测试规范。本过程"应该"不需涉及祥细设计的文字工作。

         ③. 画面设计review：由①相关的人员对产生的业务画面进行简单review，内容应该包括画面的格式、功能、程序大致要处理的数据。

         ④. 详细设计产生第二阶段:一阶段Review通过，根据①产生的CRUD图等，Tester制作单元测试数据，Coder根据编码框架、流程规范（口头或者文书）等进行画面各机能的程序框架的设计。详细设计人员开始制作详细设计，并和Coder、Tester分析数据处理中可能设计到的较为复杂的算法，必要时和共通进行讨论等。

         ⑤. 至此应该可以产生详细设计文档、单元测试数据、程序基本框架等。单元测试数据应不仅仅包括将程序正常执行完成的数据，还应该包括一跑就能使程序崩溃的数据，最好是做成生成数据的工具，便于修改和利用。

   注：前期产生较为详细的文档，便于对应变更。以上为个人见解。

2. --个人删除        

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

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

--个人注解：中日之间有很多文化差异，在日本人那边总是认为有些处理不需要明确提出，也应该在编码中进行处理的。而中方这边严格按照式样书进行编码，造成不必要的沟通问题（部分所谓的式样遗漏）。

         解决办法： 一旦发现可能产生问题，一定要立刻和客户进行沟通，得到客户的确认后，进行修改。

    补足：需要找到日方和中方认为的需要做方面不统一观点的地方。

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

 -- 日方也不是很多牛人的，有很多人都很偷懒的，所以式样书会出现不明确的地方或者非常粗略，这个就需要担当者具有相当的开发经验了。

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

--既存代码千万不可直接使用，在生成既存代码的时候，一定要写清楚入口、出口、处理功能、异常，便于后来使用。

6.--删除

7.特殊字符（比如＠、大小横线等等）的乱码问题 （NBS项目中，邮件内容就出现在过这种问题）。
   --特殊字符等文字处理，需要编码的时候使用统一的字符集。（不清楚是不是可以做成在不同的环境下可以切换字符集）。
8．追加机能的式样书，和既存代码有矛盾。
 
9.有两个案件，PT测试发现的bug数，反而比SI还要多，这是不正常的。

正常情况下，从UT到SI，再到PT，测试发现的bug数应该是正常收敛的（越来越少）。
--如果做好式样理解的时候，产生的数据CRUD图的话，相信是可以解决问题的。

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

--对日外包的式样变更大都是很正常的，但是一定要做好自己方的立场，不能是客户要求变化就立刻变化，而是要在不影响产品纳期或者是客户同意变更产品纳期的时候才进行对应。

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

 --设计好软件的构架，统一处理方式。

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

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

15.一个bug对应完之后，没有认真确认（没有横向展开（相类似的页面）和纵向展开（其他调用这段代码的地方）），导致产生新的问题。 对于这种问题，日方客户比较反感。
--修改bug，往往会产生不同的影响，最好是在式样变更的时候，对数据流程/业务流程等的修改进行标记，确认是否会产生不同的bug。
16.（测试）式样书的客户review，花费了太多时间，将项目进度拖慢了，成了项目开发进度中的一个瓶颈。

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

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

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

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

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

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