项目开发流程

        这是一个烂得不能再烂的题目，但是也是一个核心的不能在核心的的主题，如果一个项目开发流程控制得好，事半功倍，同时开发过程紧凑而不至于流于松懈，其实真正的懂得开发流程的人，凤毛麟角，因为流程不是走形式，他其实包含的是对于软件开发的理解，只有真正理解软件开发才能真正的执行好，知道哪些流程可以删减，那些节点需要增加，著名的极限开发大家不要理解为告知一套流程，他其实是一个集合，根据项目的规模和性质进行合理剪裁，这种动作的基础就是你对项目流程和管理的理解。下面简单介绍一下我对于流程的理解和把握。

        第一步，需求分析。目标：高清需求。什么叫高清需求，不是明白他让你干什么，而是要明白他要的是什么，前者只是他本意的一个具体实现，或者才是本意，天知道客户的抽象到具体能力怎么样，所以不要光听他说要这个，要那个，要通过一些发问和他的要求获知其本质是什么，开始一定要多听客户讲，后来一定要客户多听你讲，不要被客户牵着鼻子走。我比较反对过早的进入到原型阶段，因为在客户也许自己都没弄清楚想要什么的时候拿来一张页面设计除了混淆视听之外没有别的作用了。这个阶段的成果物：别给我HTML或者原型，如果你能够用文字和图形（Use Case）描述清楚明白客户的意思，才算有成果。校验：你的文字和图形你明白，同时客户也明白的。

        第二步，在第一步走踏实的基础之上，进入到了原型阶段，基于客户的愿景和范围进行原型设计，验证我们所理解的需求的表达形式（页面）可以诠释客户的意图。成果物：原型HTML/WinForm效果图。校验：你觉得你的设计体现了你理解的需求，客户也有同感。

        第三步，逻辑设计（类图）+DB设计。我很不能理解有的团队会把这两者分配给不同的角色去做，一个没有DB考量的逻辑设计图就是废纸一张。我还是坚持这两者的设计一个人来做，最次一定是先有DB设计，其次才能有逻辑设计。

        第四步，评审。没几个团队进行着一个步骤，或者即使有也是走形式，因为没有理解评审的意义。1.评审的压力会促使设计者认真对待设计本身；2. 与会者会获得信息，了解项目全貌，而且降低项目风险（一个成员的离职，其他成员会较快上手）；3.评判实现的是否合理。这里我举个例子，我们项目组评审绑定机构树的实现，最初的实际方案是树下的每个节点都需要访问DB获得其下的子节点（不要惊讶，这样实现的组员大有人在），绑定一棵树要段时间内访问上百次DB，我们当即纠正这个应该先将机构信息以某种形式读入到内存中，进行处理，否则性能肯定不过关。成果物：逻辑设计图和DB设计。校验：和原型一一对应。

        第五步，核心框架和功能的搭建。以及约束的指定。通过评审，我们可以了解项目的实现全貌，我们可以抽出共通的部分来进行核心框架的开发（异常处理机制，日志，分页实现机制等以及核心功能）；页面的搭建也需要重视，根据页面的类型都设计好Demo，谁需要直接到Demo库中进行仿造，如果没有还要再设计，千万不能放羊，因为页面样式的管理混乱造成的浪费工期的情况经常出现，还记得我在上一篇中提到的第一本程序的重要性。约束这里包括窗口的大小，弹出框的实现方式，命名规范，各种实现接口规范（比如查询，更新的接口视项目的规模决定是否要统一）。成果物：核心框架库，共同处理库，HTML/WinForm Demo库，以及规约文件。

        第六步，开发。开发必须和测试结合，我反对项目开发完毕了再进行测试，测试是经常性的，因为新完成的编码任务，测试发现的问题修改是最容易的。比方说倒炉灰，你积攒了一大缸再去倒会非常吃力，但是1/3的时候你去倒则会比较轻松，虽然会多跑几趟，却没有了量大之后的风险（大量的Bug瞬间爆发是会增加项目风险）。

测试和部署我就不多说了。

我始终这个观点，理论的东西都是有价值的，我向来鄙视轻蔑理论的人，前人总结的东西不用，却要自己来。但是有价值的东西不是执行就够的，没有什么法则是适用所有的情况，你还要真正的理解，才能正确使用，等你发觉自己知道了如何裁剪，并基于知识形成了自己的讨论，才算你入门了。