我认为回避代码是可ȝQ只要编码有意义Q我们在M阶段Q都应当投入到编码当中?/p>
最q一个项目,我下面有两个设计人员QGMz过来的Q,协助我做设计Q我做了一个设计的骨架Q然后交l他们去q代l化。下班前Q我ȝ看他们的工作只有一些空z的UML囑֒一个还没有写内容的概要设计模板Q我对他们说Q不要求你们d文Q我也没有时间去看,我不知道你们以前Q是怎么做这设计的,但在我这个组Q这样做Q不行。做计者,首先是自p理解要做的东西,q且真正知道怎么去设计它才能满涉众需求,W二步,才是让别够理解你的设计。怎么栯别h理解你的设计Q文ƈ不是唯一的途径Q对于普通程度员来讲Q白板上的讲解和直白的代码注释甚xUML图更Ҏ(gu)理解和^易近人,我们很多的设计者,L喜欢用大量的4Q? UML囑֒文档中生、冰L词汇来吓唬程序员Q恰恰反映出了设计者内心的I与胆怯?/p>
以往自n的设计经历,谈一下:
我第一ơ给另一个组做一个子模块的设计时Q心里很紧张Q因为我不在他们那个l中Q也不参与他们的开发,q个设计对于他们的项目进度来_又是一个关键\径,我生怕我自己设计的不好,考虑问题考虑的不周到Q在目后期Q如果出现问题,自己责Q重大?/p>
我对他们_q个设计需要两个星期,其实我只化了三天Q就把接口文写好了Q我对着接口考虑来考虑去,q是觉得没有底,我忍不住惛_代码Q来验证q样做对不对Q又怕别我的设计能力不强。我偷h摸的写代码,又和他们的组的主要用者反复沟通了几次Q根据需求,设计了几U不同的案例Q来验证我的设计是否有漏z?/p>
最后,又对接口修复了几ơ,觉得接口相对E_和健壮了Q就让他们过来看看,提出问题Q结果也没有提出什么问题。于是我׃工了?/p>
实事上,q个接口Q在开发后期,q是有一点修改,但ƈ没有l他们的目造成很大的媄响,他们自己也认考虑的这么全面,已经不易?br /> 做开发这么多q_来觉得设计是一个很复杂的东东,他不像徏{工E中的设计一P可以用工E化的方法去中规中矩的验证,q交l工行构造。但如果没有好的验证Ҏ(gu)Q一个设计就交工了,大家都没底。就好像选择是狮子还是公主,只有把门打开才能知道?/p>
q几q_我经历的每个目Q几乎都有评审,需求评审,设计评审{等Q但我现在回惌来,我想不出Ҏ(gu)的项目有太多的意义,很多人痴q于通过文档和评审来试图证明设计是正的Q而通过评审Q对于PM和ArchitectQ似乎也被当做是一个项目当中非帔R大的milestoneQ直到现在,我的上和我的同事,g从未改变。而我的自p点的表白在OP会上Q迎来的是批判?/p>
我认为文必要有,M的架构设计和模块的详l设计,都是需要的Q但是设计者,往往忘记了,文只是设计者自己对已经构思好的设计的一U反映,q种反映只是让别人去分析、理解、修正、接受ƈ按照它来q行开发的一个工P它绝对不是一个证明自己完成一个良好设计的Ҏ(gu)?/p>
~码、测试、调试、交付用户UATQ都应当视ؓ是设计的q程Q也应当是验证设计是否正的最好的办法?/p>
早的进入代码开发,是敏捷开发中一个很重要的标志,所谓的标志Q我认ؓ如果在项目前期的前一两个月,你仍然徘徊在需求分析、文编写的工作当中Q而没有代码生,你绝对不是敏捗这个观Ҏ(gu)我自己加的,我很隑֮忍,我的设计、分析h员天天在写文,开发h员在心猿意马的看镉K大论的需求和设计文档?br /> 一句话Q越早进入开发,我就主动?/p>
我验证设计的一些方法:
1.Ҏ(gu)以往的设计经验,做一些check list.
2.写代码,做demo。做Demo是我非常喜欢的一个方法,一个可以运行的DemoQ远胜过文了。开发h员一看,直接copy、paste完了。做汽R、计机{新产品Q都会有hQ对h做大量的试验后,才能上线Q大扚w的生产,在Y件当中,怎么一做完设计Q就大规模的q行开发了呢?br /> 3.做测试案例,TDD是一U方法,有长期开发经验的人很Ҏ(gu)吸收的思想Qƈ且愿意在重要的地方用,来理和验证自己思\?br /> 4.对于设计的涉众h员,能够早的看刎ͼq充分的沟通,不要把文档写完了Q才交给他们Q那是一U思想上的强暴。很多时候,在领导的安排下,设计人员与开发h员,在能力上Qƈ差不了多。所以设计h员要虚心Qƈ且要有责d?/p>
好的设计应当交付什么:
1. 有简z注释的代码
2. TestCase
3. Demo
4. 模型
5. 文