预计阅读本页时间：-
11.让设计指导而不是操纵开发
“设计文档应该尽可能详细，这样，低级的代码工人只要敲入代码就可以了。在高层方面，详细描述对象的关联关系；在低层方面，详细描述对象之间的交互。其中一定要包括方法的实现信息和参数的注释。也不要忘记给出类里面的所有字段。编写代码的时候，无论你发现了什么，绝不能偏离了设计文档。““设计“是软件开发过程不可缺少的步骤。它帮助你理解系统的细节，理解部件和子系统之间的关系，并且指导你的实现。一些成熟的方法论很强调设计，例如，统一过程（Unified Process，UP）十分重视和产品相关的文档。项目管理者和企业主常常为开发细节困扰，他们希望在开始编码之前，先有完整的设计和文档。毕竟，那也是你如何管理桥梁或建筑项目的，难道不是吗？
另一方面，敏捷方法建议你早在开发初期就开始编码。是否那就意味着没有设计呢？不，绝对不是，好的设计仍然十分重要。画关键工作图（例如，用UML）是不比可少的，因为，要使用类极其交互关系来描绘系统是如何组织的。在做设计的时候，你需要花时间去思考（讨论）各种不同选择的缺陷和益处，以及如何做权衡。
然后，下一步才考虑是否需要开始编码。如果你在前期没有考虑清楚这些问题，就草草地开始编码，很可能会被很多意料之处的问题搞晕。甚至在建筑工程方面也有类似的情况。在锯一根木头的时候，通常的做法就是先锯一块必须要稍微长一点的木块，最后细致地修整，直到它正好符合需求。
广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元
但是，即使之前已经提交了设计文档，也还会有一些意料之外的情况出现。时刻谨记，此阶段提出的设计只是基于你目前对需求的理解而已。一旦开始了编码，一切都会改变。设计及其代码实现会不停地发展和变化。
一些项目领导和经理认为设计应该尽可能地详细，这样就可以简单地交付给“代码工人们”。他们认为代码工人不需要做任何决定，只要简单地把设计转化成代码就可以了。就作者本人而言，没有一个愿意在这样的团队中做纯粹的打字员。我们猜想你也不愿意。
如果设计师门把自己的想法绘制成精美的文档，然后 把它们扔给程序员去编码，那会发生什么（查阅习惯39，在第152页）？程序员会在压力下，完全按照设计或者图画的样子编码。如果系统和已有代码的现状表明接收到的设计不够理想，那该怎么办？在糟糕了！时间已经花费在设计上，没有功夫回头重新设计了。团队会死撑下去，用代码实现了明明知道是错误的设计。这听起来是不是很愚蠢？是够愚蠢的，但是有一些公司真的就是这样做的。
严格的需求-设计-代码-测试开发流程源于理想化的瀑布式开发方法，它导致在前面进行了过度的设计。这样在项目的生命周期中，更新和维护这些详细的设计文档变成了主要工作，需要时间和资源方面的巨大投资，却只是有很少的回报。我们本可以做得更好。
设计可以分为两层：战略和战术，前期的设计属于战略，通常只有在没有深入理解需求的时候需要这样的设计。更确切地说，它应该只描述总体战略，不应深入到具体的细节。
前面刚说过，战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节。那应该留到战术设计阶段，它应该在项目开发的时候再具体展开。
良好战略设计应该扮演地图的角色，指引你向正确的方向前进。任何设计仅是一个起跑点：它就像你的代码一样，在项目的生命周期中，会不停地进一步发展和提炼。
下面的故事会给我们一些启发。在1804年，Lewis与Clark进行了横穿美国的壮举，他们的“设计“就是穿越蛮荒。但是，他们不知道在穿越殖民地时会遇到什么样的问题。他们只知道自己的目标和制约条件，但是不知道旅途的细节。
软件项目中的设计也与此类似。在没有穿越殖民地的时候，你不可能知道会出现什么情况。所以，不要事先浪费时间规划如何徒步穿越河流，只有当你走到河岸边的时候，才能真正评估和规划如何穿越。只有到那时，你才开始真正的战术设计。
不要一开始就进行战术设计，它的重点是集中在单个的方法或数据类型上。这时，更适合讨论如何设计类的职责。因为这仍然是一个高层次、面向目标的设计，事实上，CRC（类-职责-协作）卡片的设计方法就是用来做这个事情的，每个类按照下面的术语描述。
□ 类名。
□ 职责：它应该做什么？
□ 协作者：要完成工作它要与其他什么对象一起工作？
如何知道一个设计是好的设计，或者正合适？代码很自然地为设计的好坏提供了最好的反馈。如果需求有了小的变化，它仍然容易去实现，那么它就是好的设计。而如果小的需求变化就带来一大批基础代码的破坏，那么设计就需要改进。
好设计是一张地图，它也会进化。设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。你不要被设计（或者设计师）操纵。
切身感受
好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。
平衡的艺术
? “不要在前期做大量的设计”并不是说不要设计。只是说在没有经过真正的代码验证之前，不要陷入太多的设计任务。当对设计一无所知的时候，投入编码也是意见危险的事。如果深入编码只是为了学习或创造原型，只要你随后能把这些代码扔掉，那也是一个不错的办法。
? 即使初始的设计到后面不再管用，你仍需设计：设计行为是无价的。正如美国总统艾森豪威尔所说：“计划是没有价值的，但计划的过程是必不可少的。”在设计过程中学习是价值的，但设计本身也许没有太大的用处。
? 白板、草图、便利贴都是非常好的设计工具。复杂的建模工具只会让你分散精力，而不是启发你的工作。
