对日软件开发体会之三

多数日本企业在软件开发流程中喜欢把模块细分化，细分到一个很小很小的功能点，比如一个弹出框，一个查询按钮等等，然后每个细分好了的功能点写一本需求文档，这样做也有一定的好处。

首先，对测试人员来说容易写testcase（相对一个有很多很多操作链接的复杂页面来说，确实这样细分了的话写case的思路会清晰很多），然后写出来的case对需求的覆盖率几乎是百分之百的；

第二，对开发人员来说相同的机能点无需再次开发（比如投票模块有一个“分享给好友”的好友选择功能，在推荐模块中也同样有这么一个功能，我们在做的时候却是分别开发，这样对测试人员来说不仅增加了工作量，而且往往开发出来的两个机能点的风格不统一）。

第三，对测试人员来说对不同模块的想同机能点无需再次测试。比如评论模块，可能在一个系统的各个子产品中（如推荐、投票等）均有评论功能，在投票项目中如果已经测试了评论，那么在后期添加进来的推荐模块就不需要再次测试评论功能了，因为用的都是同一个封装。

第四，维护起来方便。可能你会认为这样的模块细分化的程度有些过分，本来我一个页面写一页UC就可以了，现在却要一个功能点写一个需求（一个页面上会有很多个功能点，比如删除、查询、添加等），会增加很多工作量，同时在代码整合的时候也需要很多的时间。其实在新增功能模块的情况下却是如此，但如果这个功能模块需要经常变动的情况下你会发现维护起来很方便，比如现在需要优化“分享给好友”这个机能，那我们只要将“分享给好友”这本需求文档做一下变动就可以了，然后开发人员和测试人员只要关注这本需求的改动背景和改动点就可以了，代码调用的接口还是一样的，无需再次整合，从而可以大大地缩短维护时间。

当然这个模块细分化的概念对我们可能并不适合，毕竟我们的项目和日常非常多，需要快速的发布产品，没有那么多的时间来搞这么多的文档，但是从中我们是否可以借鉴到某些方法来适用到淘宝呢？我想应该是有的，比如我们可以将模块细分化到一定的程度，不需要把他拆解到最小单位，这样应该能够很好的把握这个度。

以上三篇都是我的个人的一些体会和见解，语拙词穷，想到哪写到哪，可能看得不是很清楚，敬请谅解。