Top 10 过度炒作的技术和概念

• Unified Modeling Language (UML) – UML是一个程序员交流想法的不错的工具，但是他离程序员真正需要的设计工具还差得很远，比如：设计是否符合需求、架构设计、数据流等等。只有为数不多的程序员使用这个工具交流想法，而没有用在具体工作中。

• Sharepoint – 现在N多的公司都在用微软的这个东西做公司内部的Intranet。不过安装和维护起来，代价相当的大。但是其市场做的很成功，不对技术上来说对技术人员来说，相当的蹩脚。Sharepoint的设计没有认真地分析过业务流程，仅仅是一个文档存储地。看上去我们似乎可以做任何的事，但是如果你要用其来管理你的项目和track你的项目问题，你会发现其是无比的难用。

• eXtensible Mark-up Language (XML) –  XML嘛，以前说过很多了（XML1， XML2）我们用他来做和程序数据封装，用来做配置文件，用来做网络传输格式。我们的程序处理起XML来，又慢，又不经济，没有工具，几乎无法维护XML文件。XML用来做数据封包真是很不经济，Yaml和JSON那个不比它简单？用XML来做程序配置文件不知道是谁想出来的主意，相当的愚蠢，看看Unix/Linux下的配置文件，简单易读，相当容易维护。真是高科技啊。

• SOAP, XML-RPC, WSDL 的 Web Services – 这个东西前几年炒的很凶。所有人都相信，这是程序员的未来。可惜的，其中的复杂和不一致，相当的令人恶心。SOAP的那个S居然还是Simple！看来，扯上XML的都不会是什么好的东东。不过，个人认为，CORBA比他更恶。

• CORBA – 作为一个比其更恶的更过度炒作的COM技术的Linux/Unix下的补充技术，这个技术也好不到哪里去。相当的复杂，从理论上开始就是这样了。这是一个没有经过实践就搞出来的一个东西。然后开始炒作。

• Cloud Computing – 这是一个靠炒作出现的东西。这个东西也就是说，我们可以使用不同的调备，比如电脑，平板电脑，手机，移动设备随时随地做想做的事。Google的Chrome笔记本的广告展示了这项技术，但是，把工作结果放在云端的人会有多少呢。更多的人更喜欢的是去使用那些自己可以控制的电脑或平台。Google在这点上做的明显不如Amazon，像Amazon EC2平台，你可以在世界上任何一个角落随时随地的去启动你那台远程的系统。（更新（2011/1/29）：解释一下，关于云计算，在写下这篇文章的时候我本来有点拿不定主意的，后来回顾了一下历史，如COM啊，ActiveX啊，EJB啊，当时感觉都是很强的东西，但是最终也只是被炒作的。云计算，我不知道未来怎么样，从今天来看，这项技术在今天存在炒作的情况——中移动云，阿里云，到处都是云，在云面前，神马都是浮云了。）

• SOA – Service Oriented Architecture – 这是一个没有人真正知道是什么玩意的概念。炒作了很多年，很多人都试图去了解它，但最后的结果是打个哈欠，看别的东西去了。现在没有人提了。中国一些银行在IBM的鼓动下搞了很多所谓的SOA应用，结果是系统很复杂，当然，也再离不开IBM了。

• Software Industrial Process – 软件开发中有很多所谓的工业界的流程，用这些流程好像可以控制质量。外包公司和中国的本土公司很喜欢这些东西，比如ISO和CMMi，这些流程不能说不好，也有好的地方，尤其是对那些不会思考只要跟从的Worker来说。这些工业界流程中炒作过度的是，那些所谓的使用这些流程可以预测项目周期，质量控制，以前需求开发和管理等东西。其让流程上升到了一种神学的可预言的地步，同样也上升到了政治的地步。因为，这些流程中都必然会有SQA 的Audit的流程，还有统计和报告的流程，这些统统不是软件开发的流程，但是的确是相当的政治。使用这些工业届标准流程的公司，通常都是一些创造性有问题的公司。

• Agile Software Development – 敏捷开发。首先，我承认其中的很多实践相当有效，在理论上也不错，还有很多不错方法的。不过，还是有炒作的成分（下面的言论，我等着被骂）对我来说，在中国，“敏捷开发”的炒作简直就像是一个电视购物，ThoughtWorks中国各种咨询师们软件开发经验其实并不丰富，准确来说，他们有的是咨询经验，而没有具体项目实施经验（有的咨询师甚至都没有写过一行代码就去学教人怎么编程和开发软件了），和他们沟通起来能够感到他们对敏捷很亢奋，而且是唯敏捷主义，就差打出Once Process，One Agile的口号了，他们信仰敏捷流程的已经接近宗教信仰，他们的精神世界很朝鲜。因为，无论你和他们的咨询师谈什么，他们只说敏捷，从来不会分析一下，项目的特性是什么？开发这个项目的人的风格是什么？客户的特性是什么？有没有关心软件的stakeholder们（如：程序员，测试人员，客户，管理人员）是怎么想的？而XP和SCRUM也就成了Push工程师最强大的工具。流程这个东西，应该是项目组自发出来的东西，而不是被 灌输，被教条使用的东西。不同的团队、不同的项目、不同的人，不同的风格就是不同的流程，只有去使用适合自己的流程才是最好的流程。打个比方，足球队中，巴西队玩的是个人艺术足球，德国队玩的是整体和纪律性足球，意大利玩的是防守型足球，但是他们都有夺世界杯冠军的实力，如果你硬要让巴西队去整德国队或是意大利队的风格，那就悲剧了。很显然，ThoughtWorks很像把全中国的软件公司都整成Agile的，这注定了其在中国是杯具的，也只能争取到那些不知所措的公司和项目，没有合适的项目，也只有靠各种炒作（比如整一些大会，搞一些宣传）。他们总是觉得中国的用户和程序员需要去用时间不停地教育，但是，他们从来没有想想自己的原因 — 靠教育和灌输是永远赢不了的。我给他们的个人建议是，不要以为世界就像你所想像的那样，学会尊重程序员和项目还有很多非技术的东西，多听听程序员和客户怎么说，多分析一下项目的特质，从实际情况出发，而不是自己涛涛不绝地向大家灌输自己的理论。

• Object-Oriented Programming (OOP) – 不多说了，以前本站说过了，所有的一切都在面向对象是个骗局一文中。不过有一点我想告诉大家，面向对象的Design Pattern真是被滥用了，Design Pattern教你的是两件事，1）怎么去化繁为简，2）怎么能让对象的耦合性降低。而不是一个公式让你的套，但，更多的程序员则学会了“流行的设计模式编程”。

附：下构面是我拿不定是否是过度炒作的技术

Write Once Run Anywhere – 这个有点让我不解，不知道为什么会那么靠前。这是Java的口号，我觉得Java在跨平台方面还是成功的，没有过度炒作啊。用虚拟机的确是做到了这一点，对于那些需要有不同的硬件和操作系统平台并不断升级和更换它们的公司来说，这的确是个很不错的解决平台依赖性的方案。我个感觉这个技术并没有炒作过头，至少在Java这边是这样的。与其说这个，还不如说EJB，这才是炒作过度的技术。

[更新 2011/02/13]下面的回复，在我形成这篇文章的时候我没有想过，经ming同学一说，我觉得似乎有些道理。

ming :

我从一开始就觉得java的“Write Once Run Anywhere”是彻头彻尾的炒作。

想想，所谓的跨平台无非就是依靠虚拟机、解释器之类的东西实现的，那么，哪个脚本语言不是依靠解释器呢？古老的perl已经跨平台了。当然，跨平台的语言还有很多。但是，只有java炒作这个概念。

Test Driven Design (TDD) – 从测试案例开始写程序这可能是很多程序员都不习惯的方法。其实这是一种比较好的编程方法，保证了代码怎么改动都不会break其它没有改动的代码，代码可以在一种持续集成中保证质量。但是，我们需要知道TDD的一些副作用（在十条不错的编程观点里也提到过TDD的弊端）：1）TDD可能会让程序员敷衍了事，以为test case 没有错就正确了。2）TDD可能会让你忽略了软件设计和架构以及程序的扩展性和重用性。TDD只是一种方法，并不是程序的核心。当然，TDD近几年的炒作也有点过头，已经出现了“TDD是一种Design方法”等“神乎其技”的论调，我对此表示质疑中。

[更新 2011/02/13] 关于TDD，请参看我另一篇文章《TDD并不是看上去的那么美》

（全文完）

在2000年的时候，有一个苦恼的程序员，

程序员: 不好意思，我的老板这周末去打高尔夫了，现在我不得不要搞一个SOAP的应用，但是我根本不知道什么是SOAP。SOAP专家，你能帮我吗？

SOAP专家: 当然可以。首先，我要告诉你，SOAP 就是 Simple Object Access Protocol.

程序员: 哦，那么说来，他是简单的罗？

SOAP专家: 简单的就像星期天一样，我的朋友。

程序员: OK，快跟我说说。

SOAP专家: 好，就像他的名字一样，SOAP用为远程对象访问。

程序员: 像CORBA一样？

SOAP专家: 正是如此，就是像 CORBA，只是更简单。不需要复杂的传输协议，还要设置防火墙，SOAP用的是HTTP。而且我们用的是XML作为传输数据格式而不是二进制。

程序员: 听起来很不错哦，告诉我它是怎么工作的？

SOAP专家: 没问题。首先，有一个SOAP信封，其相当的简单。就是一个XML文件由head和body组成。在body中进行你的RPC调用。

程序员: 哦，这就是所有的RPC的东西？

SOAP专家: 确对是的。就像我所说的，你的RPC调用的方法名和其参数都需要写的这个XML文档的body中。方法名是在最外层的tag，每一个嵌套的子tag就是其参数。并且所有参数的类型都可以被指定，请看能规格说明书的第五节。

程序员: (阅读第五节) 还好，不算太坏。

SOAP专家: 现在，当你的服务开发完后，你需要指定endpoint.

程序员: Endpoint?

SOAP专家: Endpoint, 就是服务的地址。你需要使用HTTP的 POST 方法把SOAP 信封放到 endpoint的 URL.

程序员: 如果我使用HTTP的GET方法什么怎么样？

SOAP专家: 不知道，使用GET的行为 undefined.

程序员: 哼哼。那么，要是我把我的服务移到别的 endpoint上？我是否可以得到一个301错误？

SOAP专家: 不会的，SOAP不会返回HTTP的错误码。

程序员: 那么，当你说SOAP使用HTTP，你的意思是说SOAP在HTTP打了个洞？

SOAP专家: 哦，别说得那么难听，应该说， SOAP 是一个传输协议。

程序员: HTTP 就不是吗？那是应用层的协议啊。总之，SOAP支持了别的什么传输协议？

SOAP专家: 官方地来说没有。但是你可以潜在地支持任何的协议。而且有许多的平台支持JMS，FTP还有SMTP。

程序员: 有人用那那些协议吗？

SOAP专家: 嗯，没有。不过，我想表达的是，你能够。

程序员: 好吧。关于 SOAPAction HTTP header，这是用来做什么的？

SOAP专家: 老实说，没人真正的知道。

程序员: 那么，那些 ‘actor’ 和 ‘mustUnderstand’ 属性，是否有人用呢？

SOAP专家: 没有，真的没人用。你就忽略这些东西吧。

程序员: 好吧，让我现读一读SOAP的规格说明书。

(程序员阅读中……)

程序员: 好了，我现在几乎可以做个简单的东西了，但是我不能说我喜欢这个远程过程调用RPC的方法以及其序列化对象的方式 。

SOAP专家: RPC！对象序列化！你从哪得到的SOAP就是一堆RPC的这种印象？! SOAP是关于基于文档的消息传递啊，我的朋友。

程序员: 但是，这是你说的……

SOAP专家: 忘了我所说的吧。现在，让我们谈谈消息传递吧。其消息格式遵守XML Schema，我们把之称为新型的文件格式。

程序员: XML Schema?

SOAP专家: 哦，这是很不错的东西，未来的头等技术，你应该看一下。

程序员: (阅读 Schema 规格说明书). 上帝保佑我们！就算是亚历山大帝也搞不定它啊。

SOAP专家: 不必太担心。会有专门的工作为你来创建XML Schema。真的，这只不过就是工具上的事。

程序员: 工具是怎么做的？

SOAP专家: 好吧，他们反映了你的代码，并自动生成Schema。

程序员: 反映了我的代码？我以为这只是文档，而不是对象序列化。

SOAP专家: 你没听我说吗？这只不是工具上的事。总之，我们不能期望你来手写 XML Schema 和 WSDL。另外，这其实就是一种校正测量。你不需要读的。

程序员:  喔喔，等一下，你刚才说的那个单词是什么？ Wizzdle?

SOAP专家: 哦，我没有说过吗？WSDL. Web Services Description Language. 它让你指定你的数据类型，参数，操作名，传输绑定，以及endpoint URI，这样，所有的客户程序员就可以访问你的服务了。你应该看看。

程序员: (阅读WSDL 规格说明书)。我相信那个写下这个文章的人已经被枪杀了。其内部说明都不一致。而且，其用的是HTTP GET绑定，你不是和我说过， GET 是 undefined吗.

SOAP专家: 不必担心那个，没人会用那玩意。总之，工具会帮你生成WSDL，而且在WDSL里会有Schema的。

程序员: 但是，不应该用别的方法吗？不应该是先设计好接口然后再是生成代码吗？

SOAP专家: 是的，我猜那在原则上听起来是对的。但做起来并不容易，只有很少的SOAP栈支持先开发WSDL。让工具为这个事操心去吧。

程序员: 还有一个问题。如果我们传递 XML Schema 的消息，我们在哪里指写操作名？

SOAP专家: 好吧，你还记得 SOAPAction HTTP header吗? 绝大多数的人把操作名放在那里。

程序员: 大多数人？

SOAP专家: 嗯，这种新型并不会被写在所有的地方。

程序员: 我注意到你们整个SOAP界有很多的模糊和歧意，有些地方还是错的，并没有标准的规格说明书。实际上， SOAP 和 WSDL 规格说明书只是 W3C 的笔记罢了，连草稿都不是。

SOAP专家: 我们还在继续中。

程序员: 这个真的能行吗？能承诺吗？

SOAP专家: 绝对没有问题。

程序员: 好吧，那我去试试。

(不久以后……)

程序员: 事情变得很恶心。我这边的工具生成的WDSL居然不能被我同事的工具使用。还不仅仅是这个，其生成的XML Schemas 无法重用。而且，好像没有工具可以最好的处理SOAPAction header.

SOAP专家:  很报歉，兄弟。在光明的那一面，没人用这些文件。为了让传输独立，我们所有人都用包装好的文件。听着是不是很酷：包装好的文件？

程序员: 那是什么？

SOAP专家: 就像是原来那样，只不过，你整个消息被 包装起来成一个元素，其和操作有一样的名字。现在操作名和消息成了一体了。

程序员: 好吧，请问说明书在哪里？

SOAP专家: 哦，没有规格说明书。这只是Microsoft自己搞的。不过应该是个很不错的主意，挺不错的。然后，这是一个新玩意。我想你一定会喜欢它的—— Web Services Interoperability Group，简称 WS-I，它就是为了移除 SOAP 和 WSDL 规格说明书中的那些歧义。我知道你有多么喜欢规格说明书。

程序员: 所以，换句话说，原来的那些规格说明书太糟糕了，以致于你需要一个标准化的东西来标准化这些标准。上帝啊。好吧，那么，是否这些协调问题被 解决了？

SOAP专家: 当然，只要你使用 WS-I 的 SOAP 栈，就可以减少使用80%的 XML Schema，别用任何不同寻常的数据类型，也别期望可以和WebSphere和 Apache Axis一起运行。

程序员: 那么，是否包装的文件被在那里被解释了？

SOAP专家: 没有，但是你的工具会明白的。绝大多数，总之。

程序员: 让我总结一下，SOAP的定义是不变的，SOAP可以是任何东西，但就是简单，它不再意味着对象访问，就算是所有的工具都那样做。

SOAP专家: 基本上是对的，但是我们走得比你要远一些。我们不赞成SOAP缩写的含义。

程序员: 真的！那么SOAP是什么的缩写？

SOAP专家: 什么也不是，就是SOAP.

程序员: (无语中……)

SOAP专家: 下面让我来告诉你什么是 UDDI。

（注：我以前还认真地学过SOAP，不过真是学不懂。）

原文：来源