软件工程辩证法_软件工程

　　摘要：

　　本文用辩证法思想分析了软件工程需求和设计中的一些问题、关系、方法，探讨了轻量级和重量级软件开发过程的辩证关系。

　　要害字：

　　辩证法、软件工程、需求、设计、轻量级、重量级

　　正文：

　　近日某教授所做“智能机器的困境”的专题讲座引起了在座热烈的讨论。其中讨论得最热烈的问题就是：“某说法是唯物论，还是唯心论？”

　　其实，“某说法是唯物论，还是唯心论？”这样的争论大概是永远不会有结果的。其主要原因是：不管是唯物论还是唯心论，人们对它的概念即使是专家也不能说就完全清楚了。有些专家自以为清楚，其实并不完全清楚。更不用说普通老百姓了，只是简单地学了一些名词而已。

　　上面的观点让我们举个例子就明白了。

　　有些人认为《老子》是唯心论。另一些人认为《老子》是唯物论。有些人可能研究过，而有些人根本不知《老子》之所言为何物，也跟着喊“《老子》是XX论”。因为它确实太博大精深了，本人对他也是一知半解，在此只能谈谈自己的一些浅见。

　　《老子》的第一句是“道可道，非常道；名可名，非常名。”。其中第一个“道”可以解释为“自然的规律”，第二第三个“道”可以解释为“用语言文字描述”；第一个“名”可以解释为“事物的概念”，第二第三个“名”可以解释为“用语言文字定义”。因此，“道可道，非常道；名可名，非常名。”翻译成白话文就是“假如一个自然的规律可以被（有限的）文字语言描述，那么这样的描述就不可能是完整的一成不变的，需要根据条件变化而修正；假如一个事物的概念可以被（有限的）文字语言定义，那么这样的定义就不可能是完整的一成不变的，需要根据环境变化而调整。”。这句话实际上说明了语言文字相对于宇宙世界的局限性，而这就是《老子》的中心思想。

　　举个具体例子说明。大家都知道Jack就是某某，某某就是Jack。说起来似乎都知道了，但要唯一地说清楚Jack的全部特征却不是那么轻易的，说得够不够明白也是根据人们各不相同的需求。按姓名，有同名同姓的；加上按出生年月，也有其他同年同月的；再加上按地址，地址也是不断变化的就是连姓名都有可能变；假如再加上按体型相貌的信息，更是有限的文字（即使是二进制）无法唯一完整描述的，就像指纹信息或照片信息，根据采集的精度要求也有一定的重复率，也会根据精度的提高而增加存储的size。

　　因此，假设有一天，有个单位需要建设一个信息治理系统，其中一条需求是：要能够存储每个人的所有信息。我们能不能满足这样的需求呢？

　　答案是否定的，因为这样我们建立的数据库的表结构中就必须含有无穷多个字段才能满足这一需求。即使计算机再怎么发展，其存储空间也是有限的，也就是说即使把全世界所有的硬盘拿来也装不下一个Jack的完整信息。不要说一个人了，连一个π都装不下。

　　所以，老子的中心思想在软件工程中可以翻译成“无论什么时候，要使系统能完整地存储一个π，这样的需求都是无法满足的”，或者简单地说“即使把全世界所有的硬盘拿来也装不下一个pie”（所以as easy as pie应当改成as impossible as π）。这大概也算是所谓“智能机器的困境”中的一个吧。

　　再举《老子》中的另一句“大音希声”为例，这可以从很多角度来解读。一种可能的解释是，老子认为世界上有些声音是人们很难感觉得到的，像次声波或超声波，就可能是他所谓的“大音”, “希声”就是很少有人能够听到或感觉到（老子曰：视而不见名曰夷、听而不闻名曰希。）。假如没有人发明超声波仪和次声波仪，除了蝙蝠、海豚等等动物外，也许人们永远也无法理解这类“大音”的存在。当然，也许“大音希声”的真实含义是无法用有限的语言文字来解释的。例如，我们也可以把“大音希声”解释为“真正的大道理是很难用（有限的）文字来说明的”、“真正的大道理，人们只能感觉或发现他的很小一部分”、“掷地有声的话是不会经常听到的”或者“上好的东西是很少去用吵吵嚷嚷的方式去宣传广告的（酒香不怕巷子深）”。语言文字的能力是有限的，却给人带来无限的想象空间。

　　通过以上的例子和分析可以说明，简单地断言老子是唯物论还是唯心论是很荒谬的，因为无论唯物论还是唯心论，其概念都是人们根据自己的有限的感觉创造出来，并用人们创造出来的有限的语言文字表达的。
当然，老庄哲学在论述到具体实践时有不少相对消极的思想，这些思想是不符合时代潮流的，在当代形势下是不可取的。同时，这些思想都是学术层面上的讨论，和封建迷信没有任何联系。

　　上面所引用的老子的章句，无非是为了说明了人的感觉能力是有限的，而用来表达这些感觉的语言文字能力是更有限的。所以其弟子庄子说：用有限的语言文字来全面地描述这个浩瀚的宇宙，是MISSION IMPOSSIBLE。假如一味执著地追求，也许一切努力都只带来更多的痛苦，也许生命会在寻找中徒然逝去。能有那么一天吗，你终将你的世界占有？也可以用软件工程的术语说，需求的完整性和有效性是争对特定的时间和特定的对象而言的，随着时间和对象的改变而有可能改变。

　　所以，在争论双方无法用有限的语言文字全面地描述或解释什么是“心”、什么是“物”、什么是唯心论、什么是唯物论的情况下，或者在争论双方根本还无法完全理解什么是“心”、什么是“物”、什么是唯心论、什么是唯物论的情况下，去争论“某说法是唯物论，还是唯心论？”，是永远不会有结果的。
当然，并不是说这些争论就毫无价值，它可以开拓思路、活跃思维，至少也可以作为PASTIME、SHOW、或者作为谋生手段，创造一个又一个的商业机会和就业机会，使人们的生活丰富多彩。

　　所以，当你在参加一场辩论竞赛时，无论你抽到的是多么不可能获胜的论题，你都不要灰心，认为自己输定了。因为在辩论双方还没有把论题中的概念阐述清楚时，辩论会就已经time’s up了。裁判们主要是按照他们自己的标准，根据对你在场上的表现的印象来评判你的输赢的。辩论双方乃至裁判们可能到最后自己都没有搞清楚那些概念，甚至连刚刚在辩论什么都有可能记不得了，因为那并不重要，重要的是参与和获奖。

　　唯心论和唯物论，因为对其概念的理解的不同，他们也有不同程度的共性。其实他们都是这个世界众多观点中的一部分，是某种世界“系统模型”的从两个不同角度分析的“视图”（View）。他们都有可能被一些云雾所笼罩，或者被一些折射现象所扭曲，正所谓“横看成岭侧成峰，盲人摸象各不同，不知大千真面目，只缘身在红尘中”。

　　世上的人们各有所爱，厚此薄彼有之，兼收并蓄者有之，一概否定者有之。就像有些人喜欢白天，因为他们看到了白天的价值；有些人喜欢黑夜，因为他们看到了黑夜的价值一样。有些生物的生命如此短暂，他们上午出生，下午就死了，对这样的生物，去告诉他黑夜如何如何，不是白费力气吗？

　　白天或黑夜、天晴或下雨、炎热或严寒，去掉任何一部分，这个世界都是不完整的。所以，电影《莫斯科不相信眼泪》的主题曲说得好“自然界里没有坏天气，任何天气都是见面礼”；所以，聪明的“黄帝”在《内经》中说“智者察同”。
QQread.com 推出各大专业服务器评测 Linux服务器的安全性能 SUN服务器 HP服务器 DELL服务器 IBM服务器联想服务器浪潮服务器曙光服务器同方服务器华硕服务器宝德服务器
　　无论是萨特的《存在与虚无》，还是罗素的《哲学问题》、波普的《科学发现的逻辑》、西蒙娜·德·波芙娃的《第二性》、詹姆斯的《实用主义》等等，他们用语言构造了各种各样的思想体系，就像克隆羊多利，从无到有，从单个或数个细胞按照一定的基因规则不断地进行自我分裂、复制，直到死亡，复归到无。
难怪身陷围城的赵辛楣说：“从我们干实际工作的人的眼光看来，学哲学跟什么都不学全没两样。”。就似乎软件行业的某些人心里说，“从我们干实际工作的人的眼光看来，学软件工程跟什么都不学全没两样。”。这大概也是“智者察同”吧。

　　在日常人际交往中，我们要把自己的注重力放在彼此共同的爱好、共同的需求、共同的利益、共同的目标上，寻找自己和别人的共同之处，求同存异，这样才能做到将心比心。当你需要同事对你多关心、多交流时，先想想“己所欲、施于人”，别人也有这方面的需求，那就从我做起，主动去多关心同事、多和同事交流吧；当你心怀不满，预备贬损别人时，先想想“己所不欲、勿施于人”，别人也不希望受到贬损，那就尽可能多提建设性的方案或者是善意的批评。这样才能建立共事的基础——信任。“人与人之间的冷漠往往都是误会，没有谁故意伤害谁，只是一棵含羞草碰到了另一颗含羞草。”

　　在软件需求分析和设计中“智者察同”的思想具有相当的指导意义。例如在十多年前建设的某个信息治理系统中，对某个信息的业务可以分为登记、注销、延期、迁移、变更等等，我们当然可以把它当成不同的对象把操作日期等存储在不同的字段，其日志信息存储在不同的表中。但是，这样的结果是造成查询统计的不便、数据抽取的麻烦、更有甚者是业务类型判定的错误（当在同一天对同一个人做两种以上不同的业务时，用哪个业务的日期为最大值来判定其实际的业务类型，电脑也会“雾煞煞”）。因此，发现归纳出这些业务的共同之处非常必要。

　　在面向对象的分析设计中， “面向对象＝对象＋类＋继续＋通信”。其中“类”是一组具有相同数据结构和相同操作的对象的集合。面向对象的分析设计最基本的任务就是在搞清所有的对象后，根据不同的对象组合抽象出具有类似特性和共同行为的对象的模板，这样就形成了类。因此分析设计的水平很大程度上与分析设计者的“察同”能力与经验有关。而一个软件系统分析设计的水平，影响到这个系统在使用时的各项质量指标。

　　科学发现的过程就是在一些类似的现象中发现并证实这些现象所隐藏的共同规律的过程，就像牛顿从掉落的苹果中联想到其他下落的物体具有的共性而发现了万有引力。这些规律是用有限的语言文字来描述的，观察的环境条件也是有限的，因此会因为随着观察对象的增加、观察环境的变化、观察者的不同而需要在语言文字定义描述中加以修正完善。

　　“智者察同”的思想在当今世界企业治理理论中也在产生巨大的影响。《第五项修炼》的“共同学习”和“共同愿景”，《自适应软件开发》的“共享使命价值”，《流程治理》的“整体最优”，《瓶颈治理》中的“物流平衡”，《项目治理》中的“利益共享者”和“团队一致性”，等等等等。美国人在反省他们那种西部牛仔式的个人英雄主义，而“每个人是条龙，合起来是条虫”、“一盘散沙”的中国的软件业又该如何？

　　释迦说：“人的生命只在于呼吸之间（当下的那种平衡）”。这世界上什么人都有，有的人只喜欢吸气，有的人只喜欢呼气，有的人都喜欢，有的人都不喜欢。人在婴儿状态下是不需要（常规）呼吸的，人死了也不再需要呼吸，据说还有那些练过一定程度YOGA的是可以在几天内不需要（常规）呼吸的。但正常的人都是需要（常规）呼吸的，既需要吸气也需要呼气。因此，该吸气时就吸气，该呼气时就呼气。平衡就好，不要进气时长，出气时短；也不要进气时短，出气时长。

　　这是不是万事万物生命的辩证法呢？

　　再回首，看看古人的“智者察同”，其后一句是“愚者察异”。也许古人说的有其道理，但是“察异”者是不是就该被当成“愚者”是值得讨论的。“察同”有察同的需要和时机，“察异”也有察异的需要和时机。就像前面那个信息系统需求分析的例子，假如不能准确区别不同业务之间的区别，假如不能把系统的功能分解到底，是无法为设计提供准确而有效的依据的。就算“智者察同、愚者察异”吧，智和愚也是相对而言，而且智有智的用武之地，愚有愚的可爱之处。有时要智，有时要愚。该智时智，该愚时愚。

　　有人说，软件需求是为了说明软件系统“做什么”，软件设计是为了说明软件系统“怎么做”。这种说法本来没有什么问题，不过假如把它绝对化就有问题了。
假如把一个软件系统“做什么”分解成并联和串联的若干个“做什么”功能，并且一直分解下去的话，就似乎是在告诉大家“怎么做”了。而且在需求中也应当说明，客户原来“怎么做”，客户要求或希望“怎么做”。软件设计在说明软件系统“怎么做”的同时，也要说明预备创建出来的每一层、每个模块、每个对象、每一个类“做什么”。

　　曾几何时PSP、TSP、RUP、ISO、CMM······在中国红极一时，让许多公司投入大量人力物力财力；没过多久ASD、RAD、AP、XP、Crystal······受到众多程序员和老板的青睐，一些程序员甚至以ASD、RAD······为nickname，仿佛自己就是ASD或RAD······的化身。

　　为前者投入是因为可以提高公司的知名度和客户感觉上的档次，当然也有公司真的把它当成提高软件质量的措施之一而受益，有的公司则是为了获得某些资质不得已而为之；青睐后者是为了能够尽快地获得经济效益，在开发过程中满足客户不断变更的需求，并且可以减少项目的工作时间、成本和编写文档的烦恼。

　　前者说：“把要做的事写下来，按写的内容去做，把做的过程记下来；要不断积累经验数据，要持续改进。”；后者说：“客户注重的是可用的系统可执行程序，我们注重的是效率和人性化，要注重沟通，客户最好跟随在开发现场，我们做最简单的事情。”。都有道理。

　　前者说：“软件开发就像建造一艘战舰，要精心设计，要注重架构的合理与平衡，在施工之前要做好设计图纸的评审，并且在预备变更时要非常谨慎，不然将来下水航行就有翻覆的危险”；后者说：“这是一个客户需求和现代技术不断变化的时代，软件开发就像攀登一座从未爬过的高山，或像摸着石头过河，应该走一步看一步，随时随着客户需求的变化而变化”。
　　
　　相对而言，前者是“正规军”，后者是“游击队”。

　　前者是“理想主义”，后者是“现实主义”。

　　前者被划分到“重量级”，后者被划分到“轻量级”。

　　对于开发一个小型的软件系统来说，选择前者可能造成资源的浪费、时间的延误、各方的不满、过于复杂豪华的软件架构；对于开发一个大型的软件系统来说，选择后者可能造成软件系统架构后期的失衡、代码与设计风格的前后不一而难以维护，就像建造一座高楼，第一层是砖混式，第二层改成框架式，建到第三层时因客户需求变更只好再加一部电梯。（注）

　　精心设计的战舰，也可能因为在设计或施工中某些部分一点小小的不当或疏忽而造成灾难；号称“所见即所得”，边做、边提需求、边改、边完善的“四边形”的所谓“快速”软件开发也可能竟然是周期延续最长的项目，因为无休无止的需求变更而永无止境。

　　“银弹”在哪里？哪里有“银弹”？

　　也有人论述说：前者经过适当裁减，也可以与后者相结合。两者可以在同一个企业存在，视公司条件和具体项目情况而灵活决定，这样既可以提高公司的知名度和软件质量，也可以在必要时能够尽快地获得经济效益。

　　确实，成功的软件过程不但要将软件的质量效益最大化，将总体成本、总体周期、项目风险最小化，还必须将人们的优点最大化，将他们的缺点最小化，因为毋庸质疑每个人都存在优点和缺点，需要项目治理者扬长避短、才能充分发挥现有各项资源并达到预期目标。两者的结合不在于当有一个项目时去选择是使用前者还是后者，而是应该把两者的思想（规范性与灵活性）和方法有机地结合起来，形成能够与本公司实际情况相符合的一套软件开发体系。这是每个软件企业治理者应当思考的问题。

　　对于那些在为明日的生存而在软件大海中苦苦挣扎的小舢板来说，选择前者可能是一种奢望，选择按前者操作后果可能是要背负沉重的负担，而生搬硬套地选择前者更无异于死路一条，但假如不关注前者的趋势，不学习并且适当地实践前者的思想，就很难有所发展；而对于已经成长壮大的软件航空母舰来说，选择后者似乎有些与身份不符，或者会突破公司的规范，也有软件质量上的风险，但假如过于笨拙，也可能撞上冰山或搁浅暗礁，也可能因过多的损耗、过少的补给造成在成本、进度甚至市场上的失败而衰亡。

　　小舢板不必羡慕航空母舰的魁伟，航空母舰也不必羡慕小舢板的轻便，但这是一个不断发展前进的年代，大家都必须与时俱进，才能走进新时代。

　　什么时候，中国软件的小舢板干掉外国软件的航空母舰？

　　什么时候，中国打造出自己的航空母舰！

　　注：这仅仅是个比喻而已。用建筑或制造来比喻软件系统有其不恰当的地方，因为软件之“软”，似乎随时随处可以修改。但项目开发当事人可能因为修改的风险、成本或爱好而只做最有关系部分最简单的修改，而修改的完整性往往考虑不够周全，造成软件系统架构、代码与设计风格前后不一致的痕迹依稀可见。