设计到底需要考虑什么

设计到底需要考虑什么

by：kangtian0

       C++的具体背景知识、面向对象和设计模式经典书籍的阅读、软件开发技术管理者的精心结晶熏陶。一直认为做面向对象的软件设计，自己的能力已经完全没有问题。但是总归还没有做一个真正项目的设计，还是有点心虚。自己很自信，但是别人问用没用这些学过的知识的时候，还是哑口无言。

 

       软件工程有这样一句名言：软件工程是做出来的，不是学出来的。至于出处我已经忘记了。可能出于一种学生的锐气，或者一种对理论本身的崇敬，总认为不可能技术的经验也能算学问。

 

       这个方面我真的很难遇到知音。直到去年，终于算遇到了一个知音Bigben。不过他是否把我当知音就不得而知了。我们其实认识还是有几年了，但是去年找工作期间话才稍微多了一点，才知道他专业方面的知识很多都是我想学的。可能是因为他和我精通的领域刚好如此的没有交集，而对所谓的动手能力的理解却如此的异同，所以我很喜欢和他聊聊。我也忘了当时是怎么说到动手能力的，好像是说“动手能力有什么重要的，知道理论理解理论才有用，动手的问题有什么啊？”他这么说的：“动手能力不好，可以搞理论啊！”其实我们观点不是那么一致，不过，我却看到了我们的共同点：我们都认为理论重要。不同的地方是我认为搞理论的人不可能动手能力不强，而他认为这种人存在。他喜欢谈早期的名人，如Turing、Knuth、早期Bell实验室中C语言发明的一批人。我对C方面的名人都不知道名字，但是说到做的事情，我倒是都知道一些。我则喜欢和他说说C++方面的名人，当然不是Stanley Lippman这种人物。而是Koenig这种设计人物和Chunk这种务实主义者。提到Bjarne Stroustrup的时候，他总是会批判说：C++语法搞的太复杂了。我也是这种观点，虽然我对C++包含的设计思想总是持肯定态度，但是我评价C++时，总是说不该看哪些没有用的细小的东西，而应该看大局。我还经常说的一句话是：《C++编程思想》的第一卷只有两页纸对我有用，就是操作符重载的声明和后面的参考数目。我和他在很多地方的观点都是大方向上一致，但是有小小出入。从他那里我知道了很多还值得我去认真看的书，例如麻省理工学院计算机科学的入门书籍《计算机语言的构造与解释》。说到这里，真觉得中国教育的悲哀，我到研二才知道有这么好的一本书，而且我还是计算机的科班出身。他那里真的有太多我值得学习的地方。不过他知识很杂，不像我看的书虽然也很杂，但是都是一个方向上的，偏离的虽然很多，但是一般都不那么理解着看。所以我有一段时间一直觉得不在有好书可以看了。和他谈那么多后，我才又认识到还有大批的好书我还不曾知道。还有，他好像比我还小，比我纯真，比我有修养，性格也比我好，从他的名字和QQ上的“心中那自由的世界，如此地清澈高远”这句话，就让我羡慕不已。他真的很让我佩服，虽然他有很多时候太理想化（当然这是我的观点了）。

 

         好，说远了，我在说回来。

 

         这次，就是帮老板做一个项目。年前和其他两个人做需求，我自己写了一个实现指导手册。因为我那段时间一直看极限编程，并且这个项目的时间开发很短，所以觉得应该使用这种的方法，少设计，多迭代。当然，那时候我还没有今天的见识。

 

       现在，架构、设计以及技术问题都解决了，我觉得有些东西得说说。先说说我从需求到设计实现的状况。说实话，我对自己一向要求很严格，所以这次带着几个人做估计他们也会觉得有些事情很不爽，但是不敢说。但是，我真的对自己的这次技术上的表现而陶醉，或者说自豪。这个系统其实非常简单，第一步做的就是MIS（信息管理系统）。做这种系统没什么好自豪的，因为太没有技术含量。但是我用的和设计结果我自己很满意。说要把网络上并发请求的难点避免，因为我不敢做，做到了。说要将对象模型和界面分离，做到了。说要把网络端做成面向服务的，做到了。说要把对象模型设计成完全面向对象的，做到了。说要让客户端尽量使用渐进的方式获取数据，做到了。说要有清晰的系统概念，做到了。说要用MVC的框架思想，也做到了。并且仅仅为实现，没有任何刻意的想，自然用到的设计模式就有：Composite、Singleton、Iterator、Adaptor、Observer、Factory、Proxy。里面很多并不完全就是书面上的模式，稍许变化是因为应用的需要。例如Observer模式，所有的Subject也是Observer本身。还有继承的层次结构我也没用，觉得没有需要。因为我是写应用程序，不是写库，所以暂时不需要浪费时间在这种灵活性上。说到这里，中间也打击了我一下，曾经有一次，我把对象模型和关系数据库中的数据混淆了，导致改错了一次数据库。这算是我的很大教训。还好，不到六个小时，我就发现错误了，且中间没有人工作，当然除了我。因为那天我要加班，尽快建完对象模型，好让他们快点编码。用rational画图的时候，剪切或者复制的时候总是报0x00000004地址不能访问，也浪费我很多时间。不过，好在按时搞定对象模型，并且还画了两个时序图，作为典型的例子。很爽，工作的时候没有紧张，虽然有些不妥之处，也在周一大家开始工作的时候搞定了。

 

       说到这里，都是我的事情记录，那么这个设计到底需要考虑到什么呢？特别是这个设计实现我所有想法的时候，我真的很高兴，也发现很多人不曾说的核心思想。

 

       现在，设计主要是两种：1、强调先设计，不管实现，然后编码；2、强调代码就是设计，直接就该编码。当然，这是两个极端，多数现在的观点就是将这两者结合，用快速迭代的开发方式。所以现在大量开发模型出来了，什么极限啊、迭代啊，什么什么的都出来了。但是好像大家都遗漏了一点，到底是什么问题导致了两者的不同？

 

       是什么让他们各有优缺点？？？是信息遗失的多少，这才是问题的核心。

 

       我们可以这样来看问题。不管实现的设计，优点在于：不用考虑实现细节，专心了解需求，做到需求准确；直接设计，优点在于：直接用一个实现方式表达需求，能够立即知道时候数学化结果和想象的不同。

 

       如果用面向对象的思想来说：纯粹的设计就是一个抽象类，而纯粹的实现就是一个具体对象。那么这两种方法和信息遗失有什么关系呢？第一种方法因为没有实现，抽象的过程中容易偏离用户需求，并且通常用户本身就不完全知道需求，所以这个过程更容易遗失信息了。的二种方法因为直接实现，所以容易准确的表达当前的需求，但是他没有揭示可以允许的其他实现，也就是说他没有揭示那些处理的数据之间的真正关系，而只是这个关系的一个特例。这样，这种方法就没有包含真正的模型中允许的变化，所以这种方法会很频繁的被修改。

 

       所以现在的软件工程强调的方法确实是很科学的，但是具体情况的时候，应该那个偏重一些呢？？？为什么要考虑这个问题？这是因为没有考虑实现的设计其实是一种最快速的迭代，他的迭代是在设计者的思维中进行的。他只要想一下，有可能就进行了几次迭代，比一次实实在在的迭代少说也要快千倍吧。但是考虑到这种纯粹思想上的迭代容易偏移正常的轨道，所以还是需要实实在在的迭代来证明。这时候，就存在一个计算问题：到底在哪一个比例范围才是最好的呢？每人解决这个问题，因为这个问题的解决需要输入信息，至少需要设计者是否了解目标领域，设计者时候熟悉待使用的实现技术，设计者思想的缜密程度，当然还会有很多。

 

       我这个项目开始是2005年12月做需求，2006年春节后才开始设计和实现，当然春节年前我写了一份实现指导手册，当时自己说的是将系统遍历了3遍。不是没有遗漏，但是遗漏的部分没有影响设计和实现。我最后的设计让自己很满意，并不是我一个人能做到的。

 

       我自己对网络服务和对象模型都有充分的理论和经验，但是GUI却是我的弱项。我知道GUI如何访问对象模型来获取数据，但是却不知道GUI上的操作如何对应到对象模型上去。这一部分就是在别人的帮助下做的，最后发现其实做GUI框架的人在这个问题上考虑得很漂亮，写框架和库的人就是厉害，我真是由衷得钦佩。既然框架设计者早考虑到了，所以其实很简单就搞定了。

 

       写这篇文章，作为自己的纪念。这是我第一个带队的项目，我对自己能做到这样，真的很自豪，当然这和我用来如此长的时间吸取别人的教训和经验是分不开的，说到底，上升到理论的东西才能体现出应用的价值。

 

       以此纪念我：面向对象设计、经典设计模式、外科手术和无私奉献型团队在我第一个带队项目中的成功。

 

       没有什么比看一本好书能带给我的愉悦更多了，所以谢谢Bigben，谢谢我看的所有好书的作者，他们应该已经超过了30人。虽然他们很多名人也很多不是名人，但是他们才是真正的学者。还有谢谢告诉我很多网络麻烦的师兄们和小老师们，他们告诉我应该避免的麻烦和怎么避免。