对日软件开发体会之一
以前从事对日软件外包工作，觉得很多日本企业的开发流程过于死板，开发框架也过于老套，对开发人员的技术要求极低。但他们的文档要求却不是一般的高了。在文档这一点上我们是不是可以参考一下他们的做法。
日本人的需求文档的作者一般是项目负责人，这类人需要有很强的代码功力，因为需求文档上需要写下详细的逻辑设计，细到一个判断语句，细到一条SQL 语句。可能你认为这样很BT，因为我们总是认为设计归设计，SQL之类的都是开发人员的事情不需要在文档上写明，但这样做的好处是只要开发人员一拿到需求 文档只要完全按照文档上的思路来实现代码，原则上只要文档的思路没有错误就不允许修改逻辑（有时需求上的逻辑判断很冗余，比如a>b并且 a>c的情况下去判断b大于c，其实这样的判断逻辑开发人员觉得可以改为(a>b)&&(b>c)看起来更清晰更优 化，但这是不允许的）。因为一旦实现的代码和文档上的需求逻辑对不上就不利于维护，以后需求有变更的时候文档的修改和代码得不到统一，这样容易产生风险； 同时也不利于测试人员的用例设计(对日软件的测试倾向于白盒测试)，测试人员是根据需求文档的逻辑来写case的，一旦代码的实现和需求上的逻辑不统一， 用例就不能完全覆盖代码，这样也容易产生风险。
在这一年的对日软件开发中，我体会到日本人主要把精力放在了前期的需求文档上，文档包含了代码的实现逻辑，SQL语句的编写等等，使得在开发上花很少很少的时间就可以实现程序，产生的bug率会很低。
当然我们的UC不可能像日本人那样连代码的逻辑思路也写完整，但UC需求是不是应该由开发人员来写我这里有个疑问。首先，开发对需求了解的度应该不 是百分之百的，由他他来写UC是不是会容易遗漏细节(很多遗漏的细节在UC评审中可能会被忽略)；其次，开发写UC容易根据自己主观上的代码实现的难易程 度来适当的调整需求(他们总是有理由说如果不这样做会代码的难度会增加多少倍，但换位思考一下，要知道用户并不会因为实现技术有多难而体谅我们，用户只关 心结果)。
我觉得UC的编写是不是可以让PD或者项目经理来完成呢？由他们编写出来的需求文档我想后期需要改动的地方会很少，实现的页面用户体验也高，相对来说可以很好的减少测试人员和开发人员的沟通成本。
对日软件开发体会之二
多数日本企业在软件开发流程中各个组的组长一般只做review工作，review你的用例是否全面覆盖了你的需求，review你提交的成果物有 没有错误。Review是一份很细致的工作，需要对需求的把握十分理解。除了组长做review工作外，测试和测试之间还要做交叉测试，各自造不同的数 据，在提交成果物之前确保找出所有的bug。
这种交叉review和交叉测试的过程其实每个企业都有提到，但一方面是人力的问题，另一方面是时间的问题，似乎很少有企业能真正做到位。
然后对日软件开发中测试人员的要求比开发人员的要求高，在项目的时间计划安排上也是测试时间远远要比开发时间多，一般开发时间安排为1人/日的话， 测试时间起码是2.5人/日。因为在前面文章中我已提到需求文档上已经把所有的代码实现逻辑写好了，开发人员几乎在开发时只要将需求上的逻辑加一件“外 套”，就像现在我们使用的ruby脚本一样，在业务流代码已经完成的基础上我们只要给将业务流代码加个驱动方法使它跑起来就结束工作了；而测试人员比较辛 苦，开发人员在开发的这段时间一般还不够测试人员写TC的；在测试的时候还要保留证据证明你是完全按照case来执行测试的。比如在执行某一个用例的时候 用到了哪些数据，如果是测试前台页面的，那就需要将页面上文本框的内容截图出来，如果是测试后台批处理程序的，那么需要做一个输入数据文档，同时将程序跑 出来的日志、生成的各类统计文档等全都保留下来，将这些文档的内容和预期结果做对照，来判定测试的用例是否通过。
当然我们是否也需要花那么多的时间去做这一系列的产出物我觉得需要探讨？就目前我们的业务来说，我个人觉得没有必要，但那样做确实有一定的好处，首先很规范，不会马马虎虎一测了之；其次，一系列的输入数据文档便于回归测试，也便于下次业务有变动后可以节省造数据的时间。
对日软件开发体会之三
多数日本企业在软件开发流程中喜欢把模块细分化，细分到一个很小很小的功能点，比如一个弹出框，一个查询按钮等等，然后每个细分好了的功能点写一本需求文档，这样做也有一定的好处。
首先，对测试人员来说容易写testcase（相对一个有很多很多操作链接的复杂页面来说，确实这样细分了的话写case的思路会清晰很多），然后写出来的case对需求的覆盖率几乎是百分之百的；
第二，对开发人员来说相同的机能点无需再次开发（比如淘江湖中的投票模块有一个“分享给好友”的好友选择功能，在推荐模块中也同样有这么一个功能，我们在做的时候却是分别开发，这样对测试人员来说不仅增加了工作量，而且往往开发出来的两个机能点的风格不统一）。
第三，对测试人员来说对不同模块的想同机能点无需再次测试。比如淘江湖的评论模块，几乎在淘江湖的各个子产品中（如推荐、投票等）均有评论功能，在投票项目中如果已经测试了评论，那么在后期添加进来的推荐模块就不需要再次测试评论功能了，因为用的都是同一个封装。
第四，维护起来方便。可能你会认为这样的模块细分化的程度有些过分，本来我一个页面写一页UC就可以了，现在却要一个功能点写一个需求（一个页面上 会有很多个功能点，比如删除、查询、添加等），会增加很多工作量，同时在代码整合的时候也需要很多的时间。其实在新增功能模块的情况下却是如此，但如果这 个功能模块需要经常变动的情况下你会发现维护起来很方便，比如现在需要优化“分享给好友”这个机能，那我们只要将“分享给好友”这本需求文档做一下变动就 可以了，然后开发人员和测试人员只要关注这本需求的改动背景和改动点就可以了，代码调用的接口还是一样的，无需再次整合，从而可以大大地缩短维护时间。
当然这个模块细分化的概念对淘宝可能并不适合，毕竟我们的项目和日常非常多，需要快速的发布产品，没有那么多的时间来搞这么多的文档，但是从中我们 是否可以借鉴到某些方法来适用到淘宝呢？我想应该是有的，比如我们可以将模块细分化到一定的程度，不需要把他拆解到最小单位，这样应该能够很好的把握这个 度。
本文出自：Taobao QA Team
对日软件开发体会(转)