设计不能流于形式，为应付考核要求后补文档的方式不可取，若不是以提高设计能力做的代码反推设计，不做也罢。

　　要做迭代设计，要坚持对设计的渴望，设计不可能一蹴而就，过程是曲折的，要经历多次被推倒再重来的过程，要坚持，因为不做设计，推倒的就不是设计，而是代码，代价更大。

　　设计不是流水式的，是流程式的，是网状的，是有层级的，抽象出来是可以做程序目录的，是可以直接指导程序员开发的。说到此就明显了，只有有抽象思维、计算机思维的人才能做设计。

　　1、主要分以下几个阶段：架构设计、功能设计、流程设计、实体设计、开发设计

　　2、架构设计阶段，主要描述系统构建时的整体说明，比如系统语言、数据库类型、中间件平台、前后台交互方式等

　　不要迷恋设计，要分清哪些项目、哪些研发需要设计，因为设计很耗时，一些小项目可以精简设计阶段、甚至可以精简整个设计阶段。而且设计不能解决所有问题，当客户需求点、关注点的主体发生变化时，什么都不好使，重新立项才能解决问题。

　　3、功能设计阶段，主要包含两个部分：用例设计、活动设计，用例设计主要围绕着用户，描述用户的需求，功能层面的描述。活动设计主要是对用例的细化，梳理用户需求，描述用户的需求需要由哪些活动来支持

　　4、流程设计阶段，主要包含以下部分：模块设计、业务流程设计、数据流设计。模块设计主要将梳理后的用户需求按照功能抽象划分为不同模块。业务流程设计针对每个模块的关键业务抽象出流程图。数据流设计将业务流程打通，使得数据顺畅的在流程直接流转。在数据流设计过程，要形成数据模拟推演文档，从最初的基础数据，业务数据，到上下游处理后的结果，再到查询类报表的数据展示。涉及到算法级的流程可以不关心处理过程，但要有处理结果。

　　5、实体设计阶段，主要包含组件设计、实体数据设计、实体操作设计。组件设计根据业务流程中的环节抽象为业务组件，并定义业务流程间的业务关联关系，每个实体组件具有自己的业务职能。实体数据设计将组件拆分为基本原子单元，具有独立但不完整的业务含义，并定义实体间的关联关系。实体操作设计，赋予实体的自身的职能以及对其他实体的关联操作芒果体育，并形成接口设计。

　　其实，这件事本身很好解释。设计阶段在正常情况、或者说设计本身并不节省时间，设计节省的是在异常情况出现时减少返工工作的工作量。比如，一件事共分五步，在做完第一步的时候发现有问题，就可以停止了，没必要再进行下去了，此时要换换另一种方式。这是大家都知道的浅显道理，但落实到具体工作中就会当局者迷。以项目不做设计直接开发为例，把五步全开发完，在做另外一个业务的时候发现原来五步中的第一步错了，但是后面四步已经做了，并且要返工。这还不算最严重的情况，要命的是别的业务还需要依赖前面的五步，这五步换方式了，其他业务也要返工重做。想想看，程序员的工作定位就是一写代码的，这种时候不但要承受时间压力、加班压力，还有面临着组织的不认可，此时不单是项目无法按期交付，组织还有面临人员流失的风险，往往项目无力回天，成为烂尾项目。（说句题外话，即使知道有这种情况，也不是我能改变的，我只想谈谈设计）

　　实体主要包含几类：基础数据类、业务单据类、报表类三个层次，描述这几类实体的关系一定要用图形的方式建立网状关联关系，否则达不到目的

　　其中，类图设计可以分层级、分维度设计，比如：系统维度、模块维度、组件维度等，视系统复杂程度而定，和接口设计的方式有很大关联，通常情况以模块维度进行设计。

　　大家看过很多需求文档，是流水式的，即第一点、第二点…第N点。好一些的画一些流程图，都是节点级的，一个节点的前置节点是某个节点，后置节点是某个节点，最多加一个流程说明。再好一点的，把模块、节点、按钮整理出来，加以流水式的说明，设计过程90%以上都止于此，但这样真的就够了么、或者说有多大作用？

　　有人要说了，流水式的设计有问题么？该写的都写了，该列的都列了，功能、说明、限制都包含了，设计还需要什么？

　　上面说了，设计是连接思想和落地的纽带，上面的设计方式只是连接了一头，也就是把思想解释清楚了，但另一头没连上，直接给程序员，程序员还是迷茫。这种设计要让我下定义，我认为充其量只能算做详细需求，和设计不沾边。

　　时序图设计，指的是完成一个业务操作对需要涉及到的类、方法、对象、生命周期、输入、输出、限制条件、调用顺序等方面的完整描述。

　　算法设计，指的是操作层级看不到的，实现方式的设计。该部分对于系统功能设计影响不大，但是影响效率，如果接口设计的好，该部分后续可以想办法补救，但如果能够在前期设计则会锦上添花。主要影响范围在大数据量、大并发量上，由于硬件的发展，此部分在中小型系统设计中常被忽略，但在大型系统运行时会影响很大，想想看，当用户量很大，用户粘性很强的时候，系统做效率优化升级，将会对用户量及用户粘性产生致命的影响。

　　设计要添加到项目的最前阶段，因为设计的过程就是业务梳理的过程，可能会挖掘出客户原来没有的功能、或者业务缺失的环节。

　　设计的目标主要有两个，一个是为编码服务，一个是为项目传承。代码不是所有人能看懂的，设计除了最后的开发设计以外其他部分是能够被大众看懂的。

　　设计要多角色参与，项目经理、开发负责人、主程、测试，都要参与，必要时要让客户参与，设计过程就是团队磨合过程。

　　系统要利于维护、易扩展–这属于开发设计层面，并且属于废话，基本每个项目都有此要求，即使立项没有该要求，后续也会有此要求，属于不成为规定，说不要此要求的都是骗子，不要相信！

　　有人可能会说，互联网热潮大环境下，快是重要因素，慢了就无法占领市场，要先出个成型的东西，推向市场、快速占领市场，设计不用过于关注。

　　如果不信，可以做个试验，找两个知识背景相差无几的团队，开发一个原型产品，一个团队把主要精力放在设计阶段、一个团队拿着一句话、或者一页纸需求上来直接编码，最后看哪个团队先把产品研发出来。我估计，九成以上的情况是做设计的团队研发速度快，而且质量要好。为什么呢？因为设计的本身就是在梳理流程、完善业务，设计就是编程的一部分，设计做好了，编程对于程序员来说就是translate，这不是在贬低程序员，因为设计过程是需要程序员参与，而且该角色必不可少。

　　我们来说设计，设计本身不神秘，就是不需要懂开发语言，只要用人能懂的方式把事情描述清楚就是设计。说的容易，但想要做好，难！

　　很多软件领域内的从业者或多或少都做过设计，但鲜有人精于设计。因为，设计这一环节是想法与落地之间的纽带，也就是我们常说的Adapter，要有承接两方思维与想法的能力。

　　接口分为内部接口以及外部接口两种形式，内部接口将组件内的实体建立关联关系，将独立的组件内实体产生数据流转；外部接口将组件内的实体组合，赋予相对完成的业务含义，完成外部组件的调用要求。

　　组件间也有接口，主要为第三方系统服务，可以以接口列表的方式暴漏给第三方，也可以以统一接口暴漏，根据需要进行设计。系统内需要组件间的服务时，通常采用分别调用的方式。

　　软件开发过程是有顺序的，设计要先于编程，设计环节是重中之重，这一点不管是传统软件，还是创新类的软件，都要遵循。

　　当然了，如果是某些项目的二次开发，则另当别论，只是增加个字段、加个校验、抑或是增加个非关键性功能节点，这种开发设计不做也罢。当研发规模小到一定程度是不需要设计的、或者说是不需要过多关注设计，本文要说的是产品级、甚至是系统级的研发。

　　以上，是个人对设计阶段的理解，不全，也不充分，因为易用性设计就没在其中。主要围绕功能设计层面，易用性与客户的操作习惯等因素关联紧密，设计主体在客户与人机交互领域，关联性不大，不展开。

　　类图设计元素包含数据承载类、接口、实现类，每一个元素，要有属性定义、方法定义。类图设计过程中，设计模式起到决定性作用，将不变的部分抽象形成模板类及接口、变化的部分作为策略实现类、将策略实现类实例化的过程利用工厂类来管理、同样核心逻辑多余要求采用装饰类、领域对外Façade类、承载不同功能的Adapter类、承载事件响应功能的Listener类、随时待命的Command类、完成不同职责序列的责任链类、需要承载其他类完成某些功能的组合类、helper工具类、需要第三方完成操作的中介类，等等不一而足。

　　设计每个阶段都要出相应阶段的成果物，切忌设计碰撞后的空白，这与只开会没有会议决策结果是一个性质。

　　设计阶段中的开发设计阶段，要与设计原则、设计模式结合，开发设计要把握原则，将组件、领域、类、接口、关联关系这几个关键词时刻铭记，否则会退化为流水式设计的尴尬局面。

　　很多人都知道设计很重要，但理想是丰满的，现实是骨感的。客户、公司、项目负责人、销售等各个Stakeholders都想尽快看到成型的东西，这样才能安心。这种种因素导致程序员接触到项目的第一项工作就是编程，等项目开发到一个时间节点发现行不通了，有重要逻辑或者负责逻辑前期没想到，代码要推了重做。这种项目也就是我平时常说的“拉链工程项目”【拉链工程：我们穿衣服很多时候拉锁不好使，要拉好几个来回才能拉上，每次穿衣服都要经历这个过程，为什么不打蜡润滑一下一劳永逸呢？道路经常看到挖开个沟，埋水管，过几天再挖开步个线，过几天再挖开，铺个电缆，为什么前期不一起施工、或者留个接口呢？这里讨论概念不提工程猫腻的事】