11.让设计指导而不是操纵开发

“设计文档应该尽可能详细,这样,低级的代码工人只要敲入代码就可以了。在高层方面,详细描述对象的关联关系;在低层方面,详细描述对象之间的交互。其中一定要包括方法的实现信息和参数的注释。也不要忘记给出类里面的所有字段。编写代码的时候,无论你发现了什么,绝不能偏离了设计文档。““设计“是软件开发过程不可缺少的步骤。它帮助你理解系统的细节,理解部件和子系统之间的关系,并且指导你的实现。一些成熟的方法论很强调设计,例如,统一过程(Unified Process,UP)十分重视和产品相关的文档。项目管理者和企业主常常为开发细节困扰,他们希望在开始编码之前,先有完整的设计和文档。毕竟,那也是你如何管理桥梁或建筑项目的,难道不是吗?

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

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

广告:个人专属 VPN,独立 IP,流量大,速度快,连接稳定,多机房切换,每月最低仅 5 美元

但是,即使之前已经提交了设计文档,也还会有一些意料之外的情况出现。时刻谨记,此阶段提出的设计只是基于你目前对需求的理解而已。一旦开始了编码,一切都会改变。设计及其代码实现会不停地发展和变化。

一些项目领导和经理认为设计应该尽可能地详细,这样就可以简单地交付给“代码工人们”。他们认为代码工人不需要做任何决定,只要简单地把设计转化成代码就可以了。就作者本人而言,没有一个愿意在这样的团队中做纯粹的打字员。我们猜想你也不愿意。

阅读 ‧ 电子书库

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

阅读 ‧ 电子书库

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

阅读 ‧ 电子书库

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

前面刚说过,战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节。那应该留到战术设计阶段,它应该在项目开发的时候再具体展开。

良好战略设计应该扮演地图的角色,指引你向正确的方向前进。任何设计仅是一个起跑点:它就像你的代码一样,在项目的生命周期中,会不停地进一步发展和提炼。

下面的故事会给我们一些启发。在1804年,Lewis与Clark进行了横穿美国的壮举,他们的“设计“就是穿越蛮荒。但是,他们不知道在穿越殖民地时会遇到什么样的问题。他们只知道自己的目标和制约条件,但是不知道旅途的细节。

软件项目中的设计也与此类似。在没有穿越殖民地的时候,你不可能知道会出现什么情况。所以,不要事先浪费时间规划如何徒步穿越河流,只有当你走到河岸边的时候,才能真正评估和规划如何穿越。只有到那时,你才开始真正的战术设计。

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

□ 类名。

□ 职责:它应该做什么?

□ 协作者:要完成工作它要与其他什么对象一起工作?

如何知道一个设计是好的设计,或者正合适?代码很自然地为设计的好坏提供了最好的反馈。如果需求有了小的变化,它仍然容易去实现,那么它就是好的设计。而如果小的需求变化就带来一大批基础代码的破坏,那么设计就需要改进。

好设计是一张地图,它也会进化。设计指引你向正确的方向前进,它不是殖民地,它不应该标识具体的路线。你不要被设计(或者设计师)操纵。

切身感受

好的设计应该是正确的,而不是精确的。也就是说,它描述的一切必须是正确的,不应该涉及不确定或者可能会发生变化的细节。它是目标,不是具体的处方。

平衡的艺术

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

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

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