突破工具的习惯性思维

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

第七节化而用之，融通与融同
    ‘‘融会贯通’’出自《朱子全书》，说的是一个人能做到举一反三、闻一知十，是因为他能把知识融化汇合，因此得到全面的理解并升华。所以融通的前提，就是消化。化而用之是融通的结果和状态。
    开发人员必然会产生对开发环境、语言等的依赖。例如我早些年做软件开发，从Basic到Pascal，再后来到Delphi，每次变化都非常不适应。因为当的各种语言的开发环境(1DE)变化实在很大。后来，在DOS环境下，Borlanc为它的工具系列推出了TurboVisio开发包，使得Borland系列的开发工具，以及这些工具开发出来的许多软件产品有了相类同的界面和UI交互。再到后来，Microsoft又规范了Windows环境中的UI交互，所以大多数的工具的用法也越来越相同，例如Office系列，和Microsoft的开发类工具产品。
    在使用工具的表面上越来越规范了，并没有真正地解决“工具之用”的问题。例如大概在1999年之前，我基本上就是把Delphi当成Borland Pascal的Windows版本在用：写的代码还是“面向过程”的。那时，我习惯于声明“记录(结构)”而不是“类”；习惯于定义全局变量和函数，而不是做单例类的设计；习惯于写工具单元或公用单元，而不是做组件开发。

这些“习惯”并没有因为开发工具的变革而发生变化——习惯性思维是开发人员的通病。事实上，我对OOP的接受与理解并非是积极主动的，而是与并发活动渐进的。例如从阅读组件代码到开发新的组件，无非追赶着项目进度，应需而为的。

直到2001年的上半年的某一天，我用一个UML工具(EssModel)分析我的项目，我惊讶地发现，我原本认为“精妙”的代码都变得那么支离破碎。一些自己设计的类，与其他类之间存在那样多的“关系(Relation)”，这些纷杂的、紧密的关系表现出来的强耦合性，令我不得不重新审视自己的全部代码。
重新审视的过程伴随着对自己曾经的“成绩”的否定与批判，伴随着对“面向对象OA软件开发(OOP)”理论的认识与认知。逐渐的，我从代码的回顾中看到OO思想的源起、本质与应用，并重新阅读了超过70％的DelphiVCL源代码。在这个过程中，我将OO理论与它的实现范例进行着相互的印证，那种“深刻的惊讶”对我的影响至今犹在。

    我在充分了解OOP的理论之后，我面对种种开发语言都不再有任何畏惧。在我看来，语言间的差异越来越小，而至于此间被开发界争论不休的“编译语言好，还是解释语言好”，或者诸如“C#语言好，还是Python好”之类的争论，我都只一笑置之。
工具之用，到了融通地步，也就无所谓“选择哪个工具”了。但是所谓融通，是基于对工具背后思想的了解。如果不了解OOP，那么Delphi、Java与C#每一座都是高山大壑；反之，则可举一反三，触类旁通了。
在OOP之后，我面临的另一个障碍是“Interface(接口)”。在Delphi中，Interface的作用与价值，被OOP掩蔽得很深，再加上Delphi开发COM、WebServices等项目有自身的劣势，因此我较初理解Interface的时候，几乎茫无头绪。这一切，是直到我开始了解UML时，才醒悟的。
    因为我发现UML并不需要做CODE(现在看起来这句话真的{艮好笑)。而“做不做CODE"’，其实就是Interface与OOP的本质区别。例如UML中的接口，并不表明它的后面一定是类，或者一定是某个特定的类的实现。但类的设计，却可能与某个确定的对象实体相关，甚至会因不同的编程语言、开发环境而不同。
    之所以很多开发人员不喜欢Interface，实在是因为它与具体的“实现”距离得远了一点。而正是因为这“远了一点”，就使得很多开发人员跳不出语言的窠臼，理解不到Interface对于设计的意义。
    我开始了解Interface之后，才真正的有了“软件设计”的观念。而一旦有了工作流软件设计的观念， “实现”的过程，就变得越来越不重要。
    在一个(可以被实现的)设计面前，用什么工具去实现及实现的具体过程，其实是非常无趣的。我曾经有一段时间把这种无趣称为“痛苦”。直到我放下“有趣”与“无趣”的衡量，把“实现”看成是一个项目或工程所必须的结果时，才发现我触及了协同软件开发的本实，我才感叹：语言只是工具。
从那以后，我再也不津津乐道于某种工具或者语言。我从2003年开始，基本上就只用记事本(notepad．exe)来写Delphi代码了。事实上，《Delphi源代码分析》一书中，90％的示例程序都是用记事本写的。从2003年末开始，我用PHP、Delphi、Java、C#等都做过开发，甚至很长的时间都在使用JavaScript。
    真正做工程的人，只是简单地说：不平，刨之；不直，斗之。至于刨和斗是不是某个思想家、理论家或实践家来发明的，与用不用它，没有关系。
    然而，大多数人会谨守“不平，刨之；不直，斗之”的原则，不会赞同你把工具拿来“换个方式用”。是的，这并不是合理的做法。但在我如今看来，这个工具的“样子”是不是“刨”或“斗”都不再重要，只要能完成所需要做的事就行了。
    例如我现在就经常用MindManager来做需求分析，但偶尔也用它来画流程图；用Together来做类图、时序图、部署图，偶尔也用Visio来做相同的工作。我会选择用Delphi IDE来做软件的界面设计，但也用Photoshop或Visio、PowerPoint来做界面设计。更“可笑”的是，我甚至会选用PowerPoint来替代Delphi写代码……——我真的用PowerPoint来写代码。如果需要表达一种动态的UI效果，我可以用DelphiIDE加一些组件，并写代码来完成，也可以就用PowerPoint的“动画”来做。而我经常会选择后者。
    “写代码”并不是解决问题的唯一方式。如同PowerPoint和Visio一样可以帮助你完成软件原型。所谓“融同”，大抵如此。 “融通”与‘‘融同’’的区别在于：前者是以一通十，有运用变化的能力；后者则知工具之大同，信手而得，随心而用。
    ——无所谓是什么，只在乎它能不能用。一个工具无比强悍，但你可能只用它来输入几行代码。那么你输入这行代码就可以了，关注它那些强悍的功能干什么呢?如果你不再关注它那些强悍的功能，那么它与一个记事本又有什么不同呢?
融通是基于对“使用工具的方法、理论” 的了解；而融同，则是对“这个工具存在的本质价值”的认识。所以在我看来，UML不过是工具，RUP也不过是工具。工程实践中，用或者不用UML、RUP等，仅取决于工程本身的需要，而不取决于喜好，也不取决于现实中的大公司与外来布道者的鼓吹。
于某时某事，适用的就是较好的。前提是你要有看明白这些工具实质的能力。只要能够分辨出所需的部分、适度地用在你的工程中，就可以了，何必把它看作救世良药，一味传道布道作信徒状呢?
    融通而后融同，化而用之是对工具本质价值的尊重而非轻视。反过来说，迷信工具者，便如同食而不化者，总觉腹胀如鼓了。
第八节南橘北枳
    秦朝之后的剑技已经发展到非常高的境界。据《汉书·艺文志》记载，当时有剑道三十八篇，反映了剑术理论上的成就。但从西汉开始，剑就不再是军队中的主战兵器了。主战兵器反倒变成了刀。
这又是为什么呢?
这有两个方面的原因。一方面来说，剑的习练相对要难些，尤其在剑艺、剑道理论发展开来之后，剑术的难于掌握影响到了军队习练。相对来说，刀则沉稳简练，更便于集团性的战斗。另一方面，在汉之后，中原的主要敌人是北方的游牧民族，而骑兵交战中以砍斫为主，很少有刺的动作，这使得剑在战场上的使用价值大大下降。
    因此到了东汉末年，环柄刀几乎完全取代了剑，成为军队中主要的短兵器。
    因此剑术理论的发展，未见得就能促进剑作为武器在团队中的应用；而“刺死砍伤”的经验，也可能因为战场局势的变化，而产生相反的效果。
    因此，没有一成不变的理论，也没有一成不变的因果。如同南橘北枳，换个场景，连事物的本质都发生了变化，更何况乎工具的形状与功用呢?
    《你的灯还亮着吗》一书，就举了一个非常好的例子。
    DanDaring是一个设计打印机的工作组里的工程师。为了准确地测量出任何打印中的偏差，他建议设计一个工具，在打印纸上“印”或者“刻”一个8英寸(1英寸=2．54厘米)间隔的标志作为标准参考。
    工作组里的工程师们，都认为“打印”是在纸张上做标记的唯一方法(因为他们都是打印机设计师)。然而Dan提供的较终的解决方法，只是一根铝条，以8英寸为间隔地嵌着小针。这样，就可以很精确地在指定的点上扎出小洞来。
    然而就在老板决定提议总公司为Dan颁发一个特殊贡献奖的时候，这个小工具扎到了部门主管的屁股——因为他把这个工具