系列文章：如何做详细设计

1月 3 2015

detailed design

如何做详细设计之总结

如何做详细设计系列经过“两年”的时间终于写完了，今天主要为这个系列做下简单的总结。

详细设计没有“公式”

我们每个人从事的行业，负责的功能模块都不尽相同，不同的业务场景不同的项目特点都会产生不同的设计。可能有人会问，设计模式不是解决特定场景下的“公式”吗？设计模式是前人在具体的实践中，总结出来的解决特定业务场景的一般方法。它也不是公式，仍需要你结合自己的业务场景，具体分析。所以本系列叫如何做详细设计，只是在过去一年中，对自己工作经验的一些总结。你在本系列中看到的所有示例，都是我去年工作中的一部分。在本系列中的观点，是我在当前阶段的对详细设计的认知。也许若干年后甚至几个月后，我也会有不同的看法。所以对如何做详细设计需要有自己的看法，自己的见解。如果你对如何做详细设计有了自己的看法，或者对本系列中的观点有些其他见解，希望能和我讨论。

1月 2 2015

detailed design

如何做详细设计之设计模式

今天来讨论详细设计的最后一个内容设计模式。在我们了解一些开源源代码时，经常可以看到这些开源源代码使用了大量的设计模式，有些用的还比较灵活和巧妙。比如Sping中的bean管理部分，就大量使用了工厂模式，juint中在不多的源代码中灵活的使用了工厂方法模式、模板方法模式、观察者模式，策略模式等等，当然它们都是开源领域的经典之作。它们的作者都是业界的大师，对设计模式的理解都非常到位。其中juint的作者之一Erich Gamma也是GOF之一。我也没有分析透juint的源代码，通过网上一些大牛分析juint源代码了解到这些。分析源代码是非常有效的提高技术能力的一种方式，最近我也在思考如何分析开源源代码。对分析源代码有研究的欢迎交流讨论。有点远了，从上可以反思为什么开源代码中有那么重的设计模式呢，反观我们的设计却很少有那么好的设计，为什么呢？功力不够！^_^，回来讲我们的主题，在我们的详细设计中如何应用设计模式呢？

1月 1 2015

detailed design

如何做详细设计之重构

今天是2015年1月1日，又是一个新的开始。今天我们来讨论如何做详细设计中的重构。作为一名软件开发工程师，可能大部分都知道重构这个概念，相信也有很多人有看过Martin Flower的重构这本书，了解一些重构技巧。很多人理解的重构，就是代码结构基本上要重新设计，大部分代码需要重写，所以在实际的工作中，看到项目中的代码总是抱怨，想着什么时候能有一段时间来重构一次就好了，其实我不认为这是重构，这叫推倒重来。本文主要讲的是如何演变式的重构，每一次需求的变动重新审视目前的详细设计，并修正详细设计中的不足。从而保证代码的可持续的发展。我们将分为需求变了和如何收拾烂摊子来讨论今天的内容。本篇不涉及一些重构技巧，因为重构技巧非常多，而且不同的业务场景解决方式不尽相同。如果你想了解重构的技巧建议阅读Martin Flower大师的重构这本书。

12月 31 2014

detailed design

如何做详细设计之理解业务本质

今天来讨论详细设计中的一个重要的能力，理解业务的本质。在本系列第一篇，我们提到详细设计人员需要具备的三种能力中，其中有一条就是理解业务的本质。在做业务系统的开发中，业务是我们的核心，不管我们使用什么技术、什么设计目的只有一个为我们的业务服务。所以光有技术不行，没有业务分析能力，还是成为不了一名好的软件开发工程师。写到这里我思考了很长时间，如何来介绍本篇的内容。经过思考，我决定从深入分析业务用例、抽象公共业务模块两个工作中遇到过业务分析实例来讲解。

深入分析业务用例

在产品研发中，通常是由产品经理画出产品原型，然后进行产品原型讲解，或者出一个需求列表。研发根据原型进行分析设计，当然对于简单的需求，可以直接的看出业务用例。对于复杂的模块业务用例不容易直接看出，这时就能体现出设计者的业务分析能力的时候了，在目前做的产品中，有两个功能比较复杂，需要做详细的业务分析。我们以其中一个也是前面多次提到的阅卷模块（另一个是答题卡生成工具）。

12月 29 2014

detailed design

如何做详细设计之设计原则

今天我们来讨论一下设计原则，在详细设计的过程中，需要遵守一些设计原则，本篇的设计原则都是我自己经常思考总结，有可能有些不全，如果你已经能够很好的掌握和利用面向对象的程序设计原则，你可以不看本文。本文主要是在自己工作中的实践与体会，不讲六大原则。当然面向对象程序设计的六大原则，是我们在详细设计中要努力达到的目标。但是又有多少人望而兴叹呢。

单一职责

可能有人看到这个时，感觉我开头的话在忽悠，单一职责不就是面向对象程序设计的六大原则之一吗？是的，单一职责是六大原则之一，但是我还是要讲，我们这里分开讲，类的单一职责，方法的单一职责。

类的单一职责：类的单一职责，就是讲一个类专注于做某一件事。我还拿我们做的web业务系统说事，比如我们有一个接口类UserArchiveService，从名字看是一个用户档案业务类，但是哪天来了一个“简单”的需求。需要获取一个用户的班级信息，显然不是属于UserArchiveService类的需求，但是我们当时没有类似的类，想就这一个临时小接口，加在UserArchiveService算了，那么问题就来了，你违反了类的单一职责的原则。这样发展下去，别人也看不懂这个类到底是干嘛的了。

那么，怎么才能是职责单一了呢？

Read More

12月 23 2014

detailed design

如何做详细设计之规范

在软件开发中，很多时候都在讲规范，一般至少一个团队需要一致的规范。当然讲到规范很多人也可能想到驼峰规则、匈牙利命名法，今天我们不谈这些命名法则，遵守这些基本的法则，是做为一个程序员必备的素质。我们主要谈一些如何起名，参数列表一致性，善用注释、接口方法顺序等有趣的话题。详细设计规范了，接口实现者、接口调用者才能更好的理解接口。

起名难吗？

如果你认真的为一个方法名或者一个类名思考过或者纠结过，说明我们都在为起一个好名字而努力。以下是个人就一些场景起名的一个看法。

业务领域类，或者叫实体类，首先类名需要能够准确表达领域类的意图，比如我们一个领域类，School类，我们不可能拿它来表示班级。这是最简单的情况。
- 具备共性的领域类，使用相同的结尾或者开头，比如Archive类，档案类，另外我们根据学生、班级、学校各有一个档案的领域类，这就是一个档案类的族，我们叫UserArchive、ClassArchive、SchoolArchive等。
  Read More

12月 21 2014

detailed design

如何做详细设计之设计即编码

今天来讨论如何做详细设计的第一个内容，设计即编码。我在上篇序中开头讲到，”你只要在用心写代码，在思考如何定义方法，如何定义类，你都在做着详细设计“，其实设计本身也是在编码。当然表达设计的方式也有很多种。我比较喜欢编码这种方式。

如何表达自己的设计？

1、UML，可能大部分人谈到软件设计，想到的是UML图，当然UML作为一种工具，可以很好的表达软件详细设计的思路。UML可以非常直观的表达出设计者的意图，作为软件开发者必备的一种设计工具，也可以拿去和大多数开发人员讨论自己的设计。这种方式可以很好的表达设计思路，但是如果作为设计成果，直接拿给实现人员编写代码，实现者首先要读懂UML图，然后把UML图转化为代码，这还需要一些时间的。当然有些工具也可以生成代码。产物：UML图

12月 20 2014

detailed design

如何做详细设计之序

详细设计是软件开发中非常重要的环节，无论你是工作几年的技术大牛，还是只有一两年工作经验的小菜。可能你看到设计两个字，就觉得非常高大上，然而你只要在用心写代码，在思考如何定义方法，如何定义类，你都在做着详细设计。至于做的怎么样，那就另说了。

详细设计涉及哪些内容？

首先详细设计不同于架构设计，架构设计主要关注系统的架构模型、系统开发语言选型、系统数据存储方式选型、系统模块的划分以及系统模块间的关系，关键技术的选型，系统部署架构，系统硬件需求、系统的安全性扩展性等内容。

详细设计不同于代码实现，代码实现主要关注方法级别的算法实现，以及方法级别的调试，单元测试，以及各个模块间的接口联调。

那么详细设计是包括哪些内容？详细设计包括业务接口的定义、领域模型的定义、持久化层接口定义、关键业务设计模式的选用、关键业务模块的设计方案、关键方法的实现算法的选用等。当然如果web项目还包括请求响应接口的定义，我认为这是一个非常重要的工作。哪些地方可以使用ajax，哪些地方选用直接输出html。直接影响着响应速度以及用户体验。