帮助IT团队快速构建符合jt808协议部标的基于java技术的GPS和视频平台(2379423771@qq.com)

如何用代码推动设计


       计算机专业毕业的学生在学校当中,都读过软件工程这本书,而软件工程的书,都无一例外的,强行规定了一个编码阶段,并且十分严肃的告诉学生,代码在整个软件过程的生命周期阶段当中,只占了1/5左右。需求分析和设计、项目管理,更强于代码。我想对这于刚毕业的学生,是一种思想上的毒害,很多人刚毕业一两年,都耐不住性子,哭着喊着,要做architect,要做PM。

        我认为回避代码是可耻的,只要编码有意义,我们在任何阶段,都应当投入到编码当中。

   最近一个项目,我下面有两个设计人员(GM派过来的),协助我做设计,我做了一个设计的骨架,然后交给他们去迭代细化。下班前,我去看看他们的工作只有一些空洞的UML图和一个还没有写内容的概要设计模板,我对他们说,不要求你们去写文档,我也没有时间去看,我不知道你们以前,是怎么做这设计的,但在我这个组,这样做,不行。做为设计者,首先是自己要理解要做的东西,并且真正知道怎么去设计它才能满足涉众需求,第二步,才是让别人能够理解你的设计。怎么样让别人理解你的设计,文档并不是唯一的途径,对于普通程度员来讲,白板上的讲解和直白的代码注释甚至比UML图更容易理解和平易近人,我们很多的设计者,总是喜欢用大量的4+1 UML图和文档中生硬、冰冷的词汇来吓唬程序员,恰恰反映出了设计者内心的空虚与胆怯。


   以往自身的设计经历,谈一下:
       我第一次给另一个组做一个子模块的设计时,心里很紧张,因为我不在他们那个组中,也不参与他们的开发,这个设计对于他们的项目进度来说,又是一个关键路径,我生怕我自己设计的不好,考虑问题考虑的不周到,在项目后期,如果出现问题,自己责任重大。

       我对他们说,这个设计需要两个星期,其实我只化了三天,就把接口文档写好了,我对着接口考虑来考虑去,还是觉得没有底,我忍不住想写代码,来验证这样做对不对,又怕别人说我的设计能力不强。我就偷偷摸摸的写代码,又和他们的组的主要使用者反复沟通了几次,根据需求,设计了几种不同的案例,来验证我的设计是否有漏洞。

   最后,又对接口修复了几次,觉得接口相对稳定和健壮了,就让他们过来看看,提出问题,结果也没有提出什么问题。于是我就交工了。

   实事上,这个接口,在开发后期,还是有一点修改,但并没有给他们的项目造成很大的影响,他们自己也认为能考虑的这么全面,已经不易。
       做开发这么多年,越来越觉得设计是一个很复杂的东东,他不像建筑工程中的设计一样,可以用工程化的方法去中规中矩的验证,并交给工人进行构造。但如果没有好的验证方法,一个设计就交工了,大家都没底。就好像选择是狮子还是公主,只有把门打开才能知道。

      这几年,我经历的每个项目,几乎都有评审,需求评审,设计评审等等,但我现在回想过来,我想不出对我的项目有太多的意义,很多人痴迷于通过文档和评审来试图证明设计是正确的,而通过评审,对于PM和Architect,似乎也被当做是一个项目当中非常重大的milestone,直到现在,我的上级和我的同事,似乎从未改变。而我的自己观点的表白在OP会上,迎来的是批判。

       我认为文档必须要有,总体的架构设计和模块的详细设计,都是需要的,但是设计者,往往忘记了,文档只是设计者自己对已经构思好的设计的一种反映,这种反映只是让别人去分析、理解、修正、接受并按照它来进行开发的一个工具,它绝对不是一个证明自己完成一个良好设计的方法。

        编码、测试、调试、交付用户UAT,都应当视为是设计的过程,也应当是验证设计是否正确的最好的办法。

        尽早的进入代码开发,是敏捷开发中一个很重要的标志,所谓的标志,我认为如果在项目前期的前一两个月,你仍然徘徊在需求分析、文档编写的工作当中,而没有代码产生,你绝对不是敏捷。这个观点是我自己加的,我很难容忍,我的设计、分析人员天天在写文档,开发人员在心猿意马的看长遍大论的需求和设计文档。
          一句话,越早进入开发,我就越主动。

   我验证设计的一些方法:
   1.根据以往的设计经验,做一些check list.
   2.写代码,做demo。做Demo是我非常喜欢的一个方法,一个可以运行的Demo,远胜过文档了。开发人员一看,直接copy、paste就完了。做汽车、计算机等新产品,都会有样机,对样机做大量的试验后,才能上线,大批量的生产,在软件当中,怎么一做完设计,就大规模的进行开发了呢。
   3.做测试案例,TDD是一种方法,有长期开发经验的人很容易吸收的思想,并且愿意在重要的地方使用,来理顺和验证自己思路。
   4.对于设计的涉众人员,能够尽早的看到,并充分的沟通,不要把文档写完了,才交给他们,那是一种思想上的强暴。很多时候,在领导的安排下,设计人员与开发人员,在能力上,并差不了多少。所以设计人员要虚心,并且要有责任心。

   好的设计应当交付什么:
   1. 有简洁注释的代码
   2. TestCase
   3. Demo
   4. 模型
   5. 文档

   

 

 

posted on 2007-05-05 16:29 Speed 阅读(2011) 评论(9)  编辑  收藏 所属分类: 框架设计

评论

# re: 重视代码 2007-05-05 19:00 Thomas

写得很棒!  回复  更多评论   

# re: 重视代码 2007-05-05 22:06 Welkin Hu

我们不搞敏捷开发模式,但是在设计阶段做demo的确非常有价值。  回复  更多评论   

# re: 重视代码 2007-05-05 23:42 mixlee1

现在的人啊,才写了两三年代码就去做分析设计,唉,编码都没入门就跑去写文档,害死人啊。  回复  更多评论   

# re: 重视代码 2007-05-06 15:26 我为J狂

写得很深刻,受益匪浅。  回复  更多评论   

# re: 重视代码 2007-05-07 11:56 Zou Ang

能一次就做好一个方面,哪怕是做好90%,也是梦想了,越到后期越心惊胆战,一点改动就无语了  回复  更多评论   

# re: 重视代码 2007-05-07 13:41 轩朗=maninred

不觉得TDD是应对软件开发中需求快速变化的设计最好的方法吗?

看过XP的宣言之后,会觉得K.Back肯定了软件开发中最主要的两个因素是人和代码。  回复  更多评论   

# re: 重视代码 2007-05-07 14:39 OneEyeWolf

不要受waterfall的pattern影响, 需求是可变的,那么要求你的设计就足够的活,什么算是灵活的设计,一方面是依赖于你足够的开发经验与设计的原则,另一方面,也是XP与敏捷中,一个重要的原则,最小化的设计,不要试图去做不可以预测的、臆断的东西。软件不是铁板一块,大不了重写。
这个原理好明白,但不容易被接受。
就像用户真实的需求,是一个小汽车,你没有把握到本质,过度设计,就成了装甲车,以后用户再想变动需求,就很难做了。
  回复  更多评论   

# re: 重视代码[未登录] 2007-05-08 13:56 mgh001

你写的真好,知音呐,收藏了,但在现实中和领导决不能这么说,他们中的绝大多数更喜欢use case  回复  更多评论   

# re: 重视代码 2008-07-16 08:52 chaowei

前辈写的真好,我想做你的跟班.  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

导航

留言簿(15)

随笔分类

值得一看的博客

积分与排名

最新评论

阅读排行榜