OneEyeWolf

   以往自身的设计经历，谈一下：
   我第一次给另一个组做一个子模块的设计时，心里很紧张，因为我不在它们那个组中，也不参与他们的开发，这个设计对于他们的项目进度来说，又是一个关键路径，我生怕我自己设计的不好，考虑问题考虑的不周到，在项目后期，如果出现问题，自己责任重大。

   其实我给他们说，这个设计需要两个星期，其实我只化了三天，就把接口文档写好了，我对着接口考虑来考虑去，还是觉得没有底，我忍不住想写代码，来验证这样做对不对，又怕别人说我的设计能力不强。我就偷偷摸摸的写代码，又和他们的组的主要使用者反复沟通了几次，根据需求，设计了几种不同的案例，来验证我的设计是否有漏洞。

   最后，又对接口修复了几次，觉得接口相对稳定和健壮了，就让他们过来看看，提出问题，结果也没有提出什么问题。于是我就交工了。

   实事上，这个接口，在开发后期，还是有一点修改，但并没有给他们的项目造成很大的影响，他们本身也认为能考虑的这么全面，已经不易。

   做开发这么多年，越来越觉得设计是一个很复杂的东东，他不像建筑工程中的设计一样，可以用工程化的方法去中规中矩的验证，并交给工人进行构造。

   这几年，我经历的每个项目，几乎都有评审，需求评审，设计评审等等，但我现在回想过来，我想不出对我的项目有太多的意义，很多人痴迷于通过文档和评审来试图证明设计是正确的，而通过评审，对于PM和Architect，似乎也被当做是一个项目当中非常重大的milestone，直到现在，我的上级和我的同事，似乎从未改变。而我的自己观点的表白在OP会上，迎来的是批判。

   文档必须要有，总体的架构设计和模块的详细设计，都是需要的，但是设计者，往往忘记了，文档只是设计者自己对已经构思好的设计的一种反映，这种反映只是让别人去分析、理解、修正、接受并按照它来进行开发的一个工具，它绝对不是一个证明自己完成一个良好设计的方法。

   编码、测试、调试、交付用户UAT，都应当视为是设计的过程，也应当是验证设计是否正确的最好的办法。

   尽早的进入代码开发，是敏捷开发中一个很重要的标志，所谓的标志，我认为如果在项目前期的前一两个月，你仍然徘徊在需求分析、文档编写的工作当中，而没有代码产生，你绝对不是敏捷。这个观点是我自己加的，我很难容忍，我的设计、分析人员天天在写文档，开发人员在心猿意马的看长遍大论的需求和设计文档，一句话，越早进入开发，我就越主动。

   我验证设计的一些方法：
   1.根据以往的设计经验，做一些check list.
   2.写代码，做demo。做Demo是我非常喜欢的一个方法，一个可以运行的Demo，远胜过文档了。开发人员一看，直接copy、paste就完了。做汽车、计算机等新产品，都会有样机，对样机做大量的试验后，才能上线，大批量的生产，在软件当中，怎么一做完设计，就大规模的进行开发了呢。
   3.做测试案例，TDD是一种方法，有长期开发经验的人很容易吸收的思想，并且愿意在重要的地方使用，来理顺和验证自己思路。
   4.对于设计的涉众人员，能够尽早的看到，并充分的沟通，不要把文档写完了，才交给他们，那是一种思想上的强暴。很多时候，在领导的安排下，设计人员与开发人员，在能力上，并差不了多少。所以设计人员要虚心，并且要有责任心。

   好的设计应当交付什么：
   1. 有简洁注释的代码
   2. TestCase
   3. Demo
   4. 模型
   5. 文档