Xikug开发守则（一）----简单设计
--------------------------------------------------------------------------------
作者：xikug
Email:
xikug@163.com
HomePage:
http://www.xp-program.com
版权所有，转载请注明出处
发布日期：2004.03.03
声明：本系列文章算是我对自己这几年的开发做一个经验总结。文章中的内容不是写给初学者看的，适合有一定
软件开发经验的
软件工程师、系统分析员、项目经理看。
意图：降低开发风险和成本，设计出高质量、高稳定性、高性能的、可维护性更好符合用户需求的好程序
动机：在实际的开发工作中，由于种种原因，如需求不能描述清楚或开发人员不能理解清楚等情况经常出现，可以说99%的会
出现这样那样的失误，在开发过程中改来改去，导至设计出来的软件往往不能令用户满意，结构性差，可维护差。
在软件开发过程中我们往往要求使用软件工程中重型方法，开发时先进行需求分析，再概要设计，详细设计，编码，
测试等一系列的过程，在这个过程中如出现功能不符合需求，或设计出现错误，或实现出现错误等情况就需要返回到
前面，重新进行需求分析，设计，编码，再测试这一过程，又是成天的开会研究讨论，既要修改设计文档又要修改程序，
时间成N倍的浪费掉，结果造成产品迟迟不能推出，增加了开发成本和风险（可能失去抢占
市场的最好时机）.
可以想象，如果维护（修改）源代码的成本是x，那么同时维护文档和程序的成本是相当高的，在这一过程中如果只有1次
变动，那么成本将是2*1*X，如果变动了N次，那成本将是2*N*X。
我不是说文档没有用，因为在实际工作中要同时维护文档和源代码需要花很多的精力时间，而往往为了赶进度，都是直接先
修改程序，但又不更新文档，不能做到文档与代码同步，到最后得到的是一个“废文档”，起不了文档应有的作用，所以我
认为文档对当时的开发人员没用，文档只是一个备忘而已，和留给后来人（人员变动后）的一个参考。
因此对当时的开发人员来说，进行简单的设计，待软件成型，经过了N次修改后的时候，多次修改后的结果必定是代码
凌乱、结构性差，低质量的软件，但这时已经对用户的需求已经有了一个比较准确的把握，此时我相信大多数开发人员
已经知道该怎么做了，那就是重新进行设计，对代码进行重构，最后再形成文档，可很好的解决这一问题，同时交付给
用户的也必定是一个高质量的，可用性更好的软件。
当然如果不进行一点设计，立即编码也是不好的，至少应该明白自己要做什么。
我最近在
公司做的一个超市连锁项目中，就是一个最好的说明。我负责前台POS系统的设计和编码，这期间经常发生需求
变动(其实不是需求变动了，只是需求人员自己都没有理解，说出来的东西就经常在变，中间换了两个人，说法也不一样，
真正需求其实是很少发生变动的)，进行简单设计后就开始编码，经过前前后后N次的修改，代码总量在6000行左右，现在
需求中的问题也解决的差不多了，软件逐渐趋于稳定成熟，但是代码却乱得我都不敢看，于是在保持现有软件功能不变的
情况下我只花了3天时间，就把软件重构了一次（可以说是重新设计），代码结构跟以前完全不一样，把处理数据的部份都
封装成各种类了，运用了一些设计模式，如Factory模式、Command模式等，得到了一个可读性强，可维护性高，高稳定性，
高质量的程序代码(软件)。如果一开始我就用重型方法，可想而知我要花多少倍的精力，先把需求搞“清楚”（不可能搞清楚
的，等搞清楚的时候已经不知道是猴年马月了，有些东西得要先有看得见摸得着的，得用起来才能搞得清楚）再设计，
形成文档，按文档进行编码，再测试，再设计，修改文档，再修改编码。。。我的天，这样做累都累死了，费了力气还计不到
乖。。。所以让我们来进行简单的设计吧，简单设计确是一付良方。
原则：先要有后要好
方法：1. 对需求人员描述的功能需求进行一个简单的设计后就开始实现
2. 交给测试人员和需求人员和用户使用测试
3. 如功能不合要求则修改跳到2，如合了要求则转到4
4. 不改变功能重新设计整个程序，尽量把界面和数据处理分开，分工合作，以得到一个较好的程序结构，如有可能尽量
使用设计模式，重构代码
5. 形成一个详细的设计文档
6. 结束
文章转自:http://www.xp-program.com
