对日开发-详细设计的经验

 

式样书项目总结

今天我写这篇文章,最主要的目的就是想让大家分享下我的项目经验,希望大家以后少走弯路。能给各位带来好处的话,那我真的是很荣幸。

其实各位,一看上面的题目就知道,我是做什么的了。不错,我就是想讲讲做日本项目的经验。现在国内对日外包一直是如火如荼,沿海城市纷纷提供优惠的政策,把一些的大的企业引进到自己的城市,都想在这个对日市场上分得一杯羹。在这样的大环境下,懂日语和技术的人才就逐渐的吃香了。

现在我就说下对日开发的流程。对日开发的流程基本上分为下面的几个阶段,全体计划,要件定义,基本设计,实装,单体测试,结合测试,受入支援等。基本设计分为概要设计和详细设计。国内大部分接到的都是实装,其实也就是写代码这一块。但是从整个软件工程学的角度讲,这个部分是最不值钱的部分。估计一个 100 万的项目,代码这块也就 30 万最多了。所以一般实力差不多的公司都会接详细设计,还有后面的测试以及维护的部分全部接过来。

其实,我做的这个项目是一个改造的项目,就是把 vb 开发的系统移植到浏览器上,用 java 做。我详细说说做设计这部分,公司当时接的时候把详细设计都接了过来。因为目前经济不景气,所以老板在预算方面做的也是很少的,成本控制的很严格。我们的详细设计是按照机能来分的,大概 90 本左右吧。刚开始是另外一个同事来管这一块的。但是这个同事有一点轻敌的意识。当时他说详细设计随便写一写,就可以了。所以为后来的失败埋下了伏笔。用了 4 个人写详细设计,其中 2 个是日语一点都不会的。用汉语写的。他说找翻译给翻译下就可以了。详细设计的模板也没有,这样写了一个月后,问题接踵而至。因为和日本客户的联络,还有一个日本的窗口。客户每次都来的时候,检查详细设计,都会提出很多问题。导致项目差点失败。做日本项目的朋友都知道,日本人对于任何事情都是很认真的,精益求精,要求很严格。尤其像详细设计这样的东西,客户挑的问题主要是写法上不同意。 例如设置焦点。 有的用的是 セットする。 有的用的是 設定する。 还有有效和无效,有的用 true false 。全角数字和半角数字,标点符号的全角和半角,假名的全角和半角,句子结束时用句号等。其实这些东西在中国人看来,真的是没有什么的。例如全角和半角,看起来都是数字。但是实际上差别还是很大的。日本人都很仔细的扣这些东西。除了上面列举的这些以外,还有 excel 格式方面的,日本人似乎对 excel 都很精通,都是顶级的高手。因此对这个要求也很严格。例如打印的区域,头部,尾部设置,预览时的百分率,边框线,一条线有没有断线,对齐方式等。日本人都很严格。现在分析原因,首先不应该让不懂日语的人来写详细设计,虽然公司有翻译。如果翻译把每个人写的都翻译过去,翻译只是学习日语的,对代码不懂,在翻译的时候要花费大量的时间做调查,更多时候是找写详细设计的人员确认意思是否正确。这样的话浪费了别人的时间。原来的人写这个用了 1 天,但是翻译用了 2 天,这样翻译会很累,而且翻译的不一定正确,最主要的是还有写法上的不统一。这个就是一个最大的错误。另外 2 个人用日语写的,但是每个人的写文档的习惯和爱好不同,使用的词汇也会不同,这样写出来的东西也有差异。所以后来客户说我们基础的东西做的太差了,每次过来都是挑格式上的问题,根本没有时间看逻辑,项目的精髓所在。这样写了大约 30 本左右的东西就废掉了,造成了人员的浪费,项目的成本又增加了。

后来老板让我进这个项目,当时我就在想怎么做好这个事情呢。确实很棘手的问题。想让 4 个人写的东西都完全一模一样,是不可能的,他们刚开始写完在检查的时候都是用眼睛看的。人再仔细也有遗漏的地方,只要让日本人查到,指摘出来就是要扣钱的。很严格的客户。所以必须把好质量这个关口,这样才能出精品。得到客户的信任,和客户建立良好的信誉关系,为以后能接到项目做好铺垫。在这里我觉得有必要谈下关于标准化的问题,所有的日本项目都是,做之前先做好共同的东西,例如异常处理等,要写的格式完全一样,这就是标准化,这样做的目的就是为了便于以后的维护。假如过了几年之后,人家客户要升级系统,找到原来的代码和文档,查找起来也很方便的。我在日本工作的时候对这些东西是深有体会。好了有了标准化的概念以后,就要来实现这个标准化。首先第一步是做好模板,我们分了 7 sheet ,分别是表纸,画面,项目定义, jsp ,初期化,按钮处理,共同处理。然后在日语的书写方面我专门整理了一个文档。例如刚才说的设置,统一为 設定する。 数字全部是半角,句子结尾全部是句号等。对这些细节做了详细的规定。这样日语书写方面就统一了。但是这样规定了,后来的检查却是很麻烦的,而且很可能疏漏。这种情况下,我觉得工具应该发挥很大的作用了。因为都是在 excel 中写的,所以要使用 excel 的开发语言 vba 。本人对 vba 还是很熟悉的。根据客户提到的东西,我做了一个 checklist ,里面把需要检查的项目都罗列了出来。大概罗列了 150 多个项目,都是特别细的。这样的话从根本上避免了格式上的错误。例如检查句尾的句号,全角数字等。都用 vba 实现。每次同事写完后,直接运行我的 vba 插件,把错误查找完,然后自己改正。这样我再检查的时候就是看看有没有逻辑上的错,格式上的基本上是没有了。 后来客户来了后,发现再也找不到格式上的错误了,对本人很是佩服,一直说 すごい 这个真的就是工具的力量吧,减少了重复性劳动,提高了效率,最主要是节约了成本,以前检查的时候看一本要很长时间,现在用我的工具就 ok 了。这样我们交给客户的东西就是精品了,我算是为老板把住了质量这个关口。

各位,到这里文章就算写完了,其实我就是想说的是工具的力量,工具能很大的提高生产效率。磨刀不误砍柴工。各位以后做东西的时候,多想想用工具。真的我个人一直这么认为,虽然可能开始的时候开发工具的时间会长点,但是一旦工具完成后,它会使生产效率得到很大的提高。文章是个人的一点总结,有不足的地方,请大家多多谅解。

 

 

 

 

 

  • 7
    点赞
  • 37
    收藏
    觉得还不错? 一键收藏
  • 6
    评论
设计模式是一套被广泛接受和应用于软件开发中的解决问题的经验总结。它们提供了一种结构化的方法来设计和组织代码,以解决常见的软件设计问题。下面是一些常见的设计模式及其应用场景的详细说明: 1. 单例模式(Singleton Pattern): - 应用场景:当只需要一个全局实例时,可以使用单例模式。例如,数据库连接池、志记录器等。 - 特点:该模式确保只有一个类的实例存在,并提供一个全局访问点。 2. 工厂模式(Factory Pattern): - 应用场景:当需要根据输入参数创建多个具体对象时,可以使用工厂模式。例如,根据不同的配置信息创建不同类型的志记录器。 - 特点:该模式将对象的创建逻辑封装在一个工厂类中,客户端通过调用工厂类来创建对象。 3. 抽象工厂模式(Abstract Factory Pattern): - 应用场景:当需要创建一系列相关或依赖的对象时,可以使用抽象工厂模式。例如,创建不同操作系统下的窗口和按钮。 - 特点:该模式提供一个接口来创建一系列相关或依赖的对象,具体的工厂类实现该接口来创建不同的产品族。 4. 建造者模式(Builder Pattern): - 应用场景:当需要创建一个复杂对象时,可以使用建造者模式。例如,创建一个包含多个部分的报告。 - 特点:该模式将对象的构建过程封装在一个建造者类中,客户端通过调用建造者类来构建对象。 5. 原型模式(Prototype Pattern): - 应用场景:当需要创建大量相似的对象时,可以使用原型模式。例如,通过克隆来创建相似的图形对象。 - 特点:该模式通过克隆已有的对象来创建新的对象,避免了重复创建相似对象的开销。 6. 适配器模式(Adapter Pattern): - 应用场景:当需要将一个类的接口转换为另一个客户端所期望的接口时,可以使用适配器模式。例如,将一个类库中的接口适配为另一个类库所期望的接口。 - 特点:该模式通过创建一个适配器类来将不兼容的接口转换为兼容的接口。 7. 装饰器模式(Decorator Pattern): - 应用场景:当需要在不修改原始对象的情况下,动态地添加额外功能时,可以使用装饰器模式。例如,对一个图形对象添加颜色、边框等装饰。 - 特点:该模式通过创建一个装饰器类来包装原始对象,并在运行时动态地添加额外功能。 8. 观察者模式(Observer Pattern): - 应用场景:当一个对象的状态发生变化时,需要通知其他对象做出相应变化时,可以使用观察者模式。例如,实现用户关注功能。 - 特点:该模式定义了一种一对多的依赖关系,当一个对象发生改变时,其依赖的多个对象会自动收到通知并做出相应变化。 以上是常见的设计模式及其应用场景的简要说明。在实际软件开发中,根据具体需求和情况选择合适的设计模式,可以提高代码的可维护性、可扩展性和重用性。
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值