日本的开发习惯 第一篇

日本的开发习惯 第一篇
　
在国内做对日开发的时候对于日本的开发习惯
还没有太多的感受，只是觉得日本人做事比较
细心，有些我们认为没有必要的资料都要花那
么多精力和时间去做，很不理解。
　
我记得有一个项目日方要求用两个星期做人员
的业务说明和项目开发进度计划书之类的文档。
这个项目不算大，大概是15人左右，我觉得没有
必要花两周时间去做那些华而不实的东西，还不
如省下这时间开始开发，让开发担当尽快上手。
所以，在进度报告的时候我说是在按计划做业务
说明，但实际上已经开始编代码。因为按我们
的习惯这属于"特殊情况，特殊处理"，而且在
对日开发中也是很普遍的现象，见多不怪了。
项目进行的也比较顺利，没什么太多的波折。
项目是提前一周结束的（当然给日方的报告还
是按计划进行）。当时觉得自己的决定还挺英明，
幸亏开始的早，要不还不一定来的急呢。这个
项目过去就过去了，我当时也没有想太多。
　
做过对日项目的人可能有这么一种感受，就是
在学校里学的工程方法论根本没有用武之地。
因为项目的开发模式几乎就是固定的流程，和
工厂里的流水线没有什么太多差别。我们可以
调整的余地并不是很多。对于有想法的人或想
把理论运用到实际的人来讲这多少有点让人郁闷。
　
在日本工作了一段时间以后，我不得不开始重
新思考上面的问题。我在日本参与的很多项目
都是非常庞大的一个工程。比如拿现在的这个
项目吧，开发了大概快3年了。前前后后参与过
的人有上千人之多，参与开发的公司有数十家，
如果，没有一个很成熟的工程理论，是很难想象的。
如何尽量降低各个环节的Bug率是首先要考虑的。
因为这直接影响到开发成本和周期。日本人好像
把制造汽车里的成功管理经验拿到软件开发里来了。
他们就是把软件当成汽车来做，连部门名字都
懒得改。制造，测试，支援部门一应俱全。
好好想一想的话，好像是和做汽车没什么区别。
用一个java构架的web应用程序来举例的话，
每个零件就是一个类(class)，
车架就是框架（FrameWork,日方叫基盘），
引擎就是后台服务器(我指的是Tomcat,JBoss之类
的后台软件)。只要把这些东西有机结合在
一起就可以组成一个应用程序。和实现了自动化
流水线的制造不同的是程序大部分还是需要程序员
的手工制造，所以不良率要比制造高很多，质量
控制也难很多。