zoukankan      html  css  js  c++  java
  • 让设计指导而不是操纵开发

    ——摘自《敏捷开发修炼之道》

    在开发过程中,有时候我们会陷入一个误区:设计文档应该尽可能详细,这样,低级的代码工人只要按照设计文档敲代码就可以了,在高层方面,详细描述对象的关联关系;在底层方面,详细描述对象之间的交互。其中一定要包括方法的实现信息和参数注释等等。

    设计是软件开发过程中不可缺少的步骤。它帮助你理解系统的细节,理解部件和子系统之间的关系,并且指导你的实现。一些成熟的方法论很强调设计,例如,统一过程(UP)十分重视和产品相关的文档。项目管理者和企业主常常为开发细节困扰,他们希望在开始编码之前,先有完整的设计和文档。毕竟,在建筑行业是这样的。

    另一方面,敏捷方法建议你早在开发初期就开始编码。是否那就意味着没有设计呢?不,绝对不是,好的设计仍然十分重要。画关键工作图(例如,用UML)是必不可少的,因为要使用类及其交互关系来描述系统是如何组织的。在做设计的时候,你需要花时间去思考和讨论各种不同选择的缺陷和益处,以及如何做权衡。

    然后,下一步才考虑是否需要开始编码。如果你在前期没有考虑清楚这些问题,就草草开始编码,很可能会被很多意料之外的问题搞晕。甚至在建筑工程方面也有类似问题。在锯一根木头的时候,通常的做法就是先锯一根比需要稍微长一点的木头,最后细致地修整,直到它正好符合需求。

    但是,即使之前已经提交了设计文档,也还会有一些意料之外的情况出现。时刻谨记,此阶段提出的设计只是基于你目前对需求的理解而已。一旦开始了解编码,一切都会改变。设计及其代码实会不停的发展和变化。一些项目领导和经理认为设计应该尽可能详细,这样就可以简单地交付给“代码工人们”。他们认为代码工人不需要做任何决定,只要简单地把设计转化成代码就可以了。就本人而言,没有一个人愿意在这样的团队中做纯粹的打字员。

    设计满足实现即可,不必过于详细

    如果设计师们把自己的想法绘制成精美的文档,然后把它们扔给程序员去编码,那会发生什么?程序员会在压力下,完全按照设计或者图画的样子编码。如果系统和已有的代码的现状表明接收到的设计不够理想,那该怎么办?那就太糟糕了!时间已经花在设计上了,没有功夫回头重新设计了。团队会死撑下去,用代码实现了明明知道是错误的设计。这听起来是不是很蠢,但是有些公司真的就是这样做的。

    严格的需求——设计——编码——测试,开发流程源于理想化的瀑布式开发方法,它导致在前面进行了过度的设计。这样在项目的生命周期中,更新和维护这些详细的设计文档变成了主要工作,需要时间和资源方面的巨大投入,却只有很少的回报。我们本可以做得更好。

    战略设计和战术设计

    设计可以分为两层:战略和战术。前期的设计属于战略,通常只有在没有深入理解需求的时候需要这样的设计。更确切地说,它应该只描述总体战略,不应该深入到具体的细节。

    如果你自己都不清楚所谈论的东西,就根本不可能精确的描述它

    ——约翰 冯 诺伊曼

    前面刚说过,战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节。那应该留到战术设计阶段,它应该在项目开发的时候在具体展开。良好的战略设计应该扮演地图的角色,指引你想正确的方向前进。任何设计仅是一个起跑点:它就像你的代码一样,在项目的生命周期中,会不停地进一步发展和提炼。

    设计就像我们穿越蛮荒一样,我们不知道在穿越蛮荒会遇到什么样的问题。只知道我们的目标和制约条件,但是不知道旅途的细节。软件项目中的设计也有类似问题,在没有穿越蛮荒的时候,你可能不知道会出现什么情况,所以,不要事先浪费时间规划如何徒步穿越河流,只有当你走到河岸边的时候,才能真正评估和规划如何穿越。只有那个时候,你才开始真正的战术设计。

    不要一开始就进行战术设计,它的重点是集中在单个的方法或数据类型上。这时,更适合讨论如何设计类的职责。因为这仍然是一个高层次、面向目标的设计。事实上,CRC(类-职责-协作)卡片的设计方法就是用来做这个事情的。每个类按照下面的术语描述。

    • 类名。
    • 职责:它应该做什么?
    • 协作者:要完成工作它要与其他什么对象一起工作?

    如何知道一个设计是好的设计,或者正合适?代码很自然地为设计的好坏提供了最好的反馈。如果需求有了小的变化,它仍然容易去实现,那么它就是好的设计,而如果小的需求变化就带来一大批基础代码的破环,那么设计就需要改进。好的设计是一张地图,它也会进化,设计指引你向正确的方向前进,它不应该标识具体的路线,你不要被设计(或者设计师)操纵。好的设计应该正确的,而不是精确的。也就是说,它描述的一切必须是正确的,不应该涉及不正确或者可能或发生变化的细节,它是目标,不是具体的处方。

    “不要在前期做大量的设计”并不是说不要设计。只是说着没有经过真正的代码验证之前,不要陷入太多的设计任务。当对设计一无所知的时候,投入编码也是一件危险的事。如果深入编码只是为了学习或者创造原型,只有你随后能把这些代码扔掉,那也是不错的办法。

    即使初始设计到后面不再管用,你仍需设计:设计行为是无价的。正如美国总统艾森豪威尔所说“:计划是没有价值的,但是计划的过程是必不可少的。”在设计过程中学习是有价值的,但设计本身也许没有太大的用处。

    白板、草图都是非常好的设计工具。复杂的建模工具只会让你分散精力,而不是启发你的工作。

    Martin Fowler文章:设计已死(Is Design Dead?)是对设计讨论更深入的一篇好文章(中文版百度文库)

  • 相关阅读:
    Java并发基础知识点总结
    Java中的可重入锁(2)
    Java中的可重入锁
    多线程的共享变量的内存不可见性
    JavaWeb 案例3— Cookie案例
    JavaWeb 案例2—response案例
    JavaWeb 之 三层架构(MVC架构):软件设计架构
    JavaWeb 之 备用9
    JavaWeb 之 备用6
    JavaWeb 之 备用7
  • 原文地址:https://www.cnblogs.com/luoht/p/2551766.html
Copyright © 2011-2022 走看看