日本的开发习惯 第三篇

日本的开发习惯 第三篇
　
很多对日开发程序员都在抱怨，对日项目没有
什么技术可言，日方规定的过于死板，没有留
一点想象和发挥空间。是啊，其实这就是外包
开发的矛盾点。对于我们个人来讲也许前沿的
技术，新颖的概念更有吸引力。但对于日方公司
而言任何不确定因素都代表着风险。设想一下
如果有一个功能可以用一个成熟但没什么新意
的方法可以实现。也可以用一个没有经过实践
验证但很有技术前景的方法实现的话你会选择
哪一个呢？我想多数程序员喜欢后者，但日方
肯定选择前者。很显然，因为哪一天系统崩溃
了赔偿的可就不是几千，几万的问题了。公司
损失会很大，甚至面临破产的危险。在这一点上，
确实是无法调和的矛盾。这种矛盾不只是在对
日外包项目上存在，在国内项目中也是普遍
存在的。
　
日方的要求其实很简单，因为给你的设计书
已经把要求和过程写的非常清楚了。你只要
按照我们规定好的步骤进行编码就可以了。
不需要你变化太多，也不喜欢你随便改变
成熟的开发步骤，这就是为什么在第一篇里
提到的日方给我们两周时间去进行说明和培训的
原因。他们认为这是顺利进行开发的必要条件。
这也是他们在开发大型项目的时候得出的结论。
至于这个结论是否适用于外包项目日方可能
没有充分考虑。反正他们觉得这就是对的，你
要严格执行。我在国内和日本都带过项目，感觉
双方的开发人员在执行力方面有很大的差别。
日本开发人员非常遵守开发规则，所以只要你
规定好规则，就不用担心得不到执行。结果也是
和你预料的不会有太多出入。国内的开发人员
则不同，一般不会完全按照规定去执行，
而是会按照自己的想法，用自己认为最好的方
式去执行，所以往往结果也是出乎你的意料
这时候，只能是通过定期检查和沟通来
了解情况。要不等项目快结束的时候才发现和你
要求的不一样，那就有的你苦头吃了。
这就是双方开发文化的区别。倒不是说哪一种方式
更好，单从管理成本上来讲，显然前者要更低。
这也是为什么日方喜欢把规定定的很死的原因之
一吧。另一方面，把规定写的详细一点，比较
容易控制。举个例子来讲的话，你打算让
一位日本程序员A和一位中国程序员B,从城市X去
城市Y。你想两个人会选择什么样的方式实现。
很可能的选择是两个人都会乘坐从X到Y的飞机，
只是日本程序员会坐普通舱而中国程序员
会坐头等舱。为什么不呢？即舒服速度又快。
为了防止这种情况发生你添加了一条只许乘坐
火车的规定，日本程序员会乘坐最便宜的D路线
到达Y城市。中国程序员会坐最短路线F到达Y城市。
你想要什么样的结果呢？更快？还是更便宜？
那么最好把路线也规定下来。
　
最后我们在讲讲测试，有时候我们会觉得日方对
Bug率和测试件数很敏感。总是希望我们如实填写。
而我们则希望尽量填的少一点。其实这是因为我们
的出发点完全不同。日方是根据Bug率和测试件数
来推测软件质量的。他们认为一定的程序规模中
存在一定的Bug率，如果达不到就说明测试不过充分，
而且也是根据Bug曲线来进行进度安排的。认为到了
项目后期，Bug曲线应该是下降趋势才是正常的。
这些可能也是从工业制造的成品率演化过来的吧。
但我们则观念里则认为Bug越少越好，越少证明
程序质量越高。结果可想而知。
　
上面谈了一些我比较了解的日本开发习惯。还有很多
其他的方面以后有时间再写。