那些炒作过度的技术和概念

那些炒作过度的技术和概念

StackExchange.com上有一个贴子在评论着最近20年来被炒作过度的技术,对于出现的结果,大多数赞同,也有一些不赞同。下面我从前15名挑了10个(Java的WORE我去掉了,TDD我也去掉了,因为我觉得他们应该没有炒作过度,而且都不错),按原贴的顺序罗列如下:(后面的一些评论是我加的,欢迎大家讨论)

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并不是看上去的那么美

(全文完)

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (34 人打了分,平均分: 3.91 )
Loading...

那些炒作过度的技术和概念》的相关评论

  1. @Tin
    关于敏捷,基本同意楼上的说法,虽然敏捷方法的共同点是迭代,但是个人认为敏捷其实强调的是更快速的响应变化,加速反馈频率,减少应对变化的延迟。迭代更多的也是实践一级的东西。个人分析任何方法,都由价值,原则,实践三个级别去考虑。如果快速反馈能创造价值,那么敏捷的原则就是有帮助的,那么实践也就是可以使用的,反之,可能敏捷就不适用或者说暂时不适用。

  2. 我从一开始就觉得java的“Write Once Run Anywhere”是彻头彻尾的炒作。
    想想,所谓的跨平台无非就是依靠虚拟机、解释器之类的东西实现的,那么,哪个脚本语言不是依靠解释器呢?古老的perl已经跨平台了。当然,跨平台的语言还有很多。但是,只有java炒作这个概念。

  3. ming :

    我从一开始就觉得java的“Write Once Run Anywhere”是彻头彻尾的炒作。
    想想,所谓的跨平台无非就是依靠虚拟机、解释器之类的东西实现的,那么,哪个脚本语言不是依靠解释器呢?古老的perl已经跨平台了。当然,跨平台的语言还有很多。但是,只有java炒作这个概念。

    经你这么一说,我也开始觉得好像真是这么一回事了。

  4. web service是很好用的数据集成与通讯工具。

    如果web service能解决接口版本的兼容性问题就更好了。

  5. wwccss :
    xml我也是深恶痛绝,呵呵。能不碰就不碰。简直是老太婆的裹脚,又臭又长。oop方面不敢苟同,我之前也很排斥它,但尝试去用oop来写东西,慢慢去理解,观点在逐渐的改变。云计算的东西,我想是一个趋势,其实整个互联网一直就是云计算。只不过现在大家明确的提出了一个概念。就像ajax一样。我看好它。其实你自己都在每天使用云计算的东西啦。

    你现在还在开始理解oop,那真得是太晚了。

  6. 不同意对xml, oop, 云计算、web service,敏捷开发 这几个东西的说法。

    xml有其他数据语义标准之长,而无之短,只是语法上上有点儿冗余,但是这东西主要还是让计算机看的,捎待让人看懂已经很不错了。如果你玩过银行里那种古系统中的文本文件数据报文你就知道xml的好了。xml还有一整套配套的技术,如xmldoc, xpath等辅助使用。

    oop与设计模式不是一回事,oop的思想根本上是把现实世界在计算机中建立映射,这是很好很有效的降低开发复杂度的办法。设计模式是是在oop基础上的算法总结,是指导而非要求。你要反对的是学院派由于《设计模式》一书的存在而过度设计,而非是oop本身。但是,当你系统扩展弹性要求高了之后,你会发现答案还是设计模式中的一些办法。

    web service的最好的解决平台间数据通讯的技术了。但是如果都解决接口版本的兼容性问题就更好了。中立的数据类型,支持对象的语法规则,中立的通讯协议,自动代理方法工具,甚至连异常都能跨平台传输,你还需要啥呢?
    不过,它的确不是万用法宝,它只能解决他适合解决的问题。ibm最会炒概念,你迷信ibm是你无知, webservice仍然工作得让人安心。

    敏捷开发的一个潜台词是“高手开发”,“敏捷” 的核心就是:深刻理解业务需求 + 合适(成本、可扩展性的均衡)地实现需求+ 一有必要立即重构以增加设计弹性 + tdd(质量保证)。所有这一切都需要高手才能做到。
    对于大型的系统,我的实践经验是:在架构设计层面(系统设计、程序结构设计、数据库设计等),高手进行“敏捷式设计”,而具体的实现可由普通开发人员完成,一则提供优秀的系统设计、为未来始终留下扩展余地,二来也不会过度设计导致实现成本过高,三来普通的开发人员的工作也好干。

    题外话:与高手一起工作的惬意无与伦比。

    云计算:其实这是一个基础运行体系的解决方案,在专业it运行领域,虚拟化、基于冗余思想的高可用硬件是多年以来企业级厂商努力的方向。
    虚拟化有两个方向,一个是把一个高性能的硬件分为多个虚拟机运行,如ibm的高端机型,另一个方向是把多个物理机整合为一个虚拟的单一机器,任务分散、分布执行,从而得到高性能计算能力。
    云的意思是两者的结合——多个物理机整合为一个虚拟机,这个一个虚拟机上再分为多个独立的汉人逻辑单位,用于隔离不同的应用程序运行空间。这样,即得到了应用程序管理的便利,又得到了冗余硬件的可靠性,以及高弹性的性能管理。只要你做过基础运维你就会理解这个东西的宝贵。

    一个IT经理高声呼喊,快点到来吧,云计算!我需要一个私有云来解放我!

  7. @hal9000
    望文生义,我说的尝试去理解,那已经是四年前的事情了。古人云,问道有先后,不见得某些人自诩的精通oop,写出来的代码就很oop。搞不好也是老太婆的裹脚。
    不要拿是否了解oop,是否写出来的代码一定符合什么什么标准才合适。我看过一个哥们写的完全按照某种设计模式写的代码,我承认,我写不出来。他的代码可以适应后面n多种的变化组合,但这n多种的变化,后面也许一种都没有发生。我的东东已经在上线运行了,他的还在编码阶段。
    so,oop也只是一种思想,工具,不要将其教条化,不要神化,也不要妖魔化。
    这篇文章就是一篇口水帖,一大堆的愤青在这儿可劲的贡献自己的水贴。hoho,我也痒痒,多说了几句。anyway,管他什么xml,管他什么敏捷,管他什么oop,管他什么神马浮云,只要能够work,能够解决问题,就是好的。没有防止四海而皆准的东东。

  8. 我本人是敏捷的实践者,从Potian先生介绍敏捷给我,到现在敏捷实践已达9年。早年还参与一些讨论,但现在别人怎么炒作我不清楚,已经很少参与扯闲淡(除了自己的团队)。

    我个人在五家企业,使用并普及了敏捷管理,成功的推广并使用了敏捷管理。 总得来说,敏捷是适合快速递交,降低成本,帮助团队成长的。有些实践也做了一些个人的改造(限于环境和项目现实)。

    我想本文作者对敏捷这块的评价是不恰当的,带有强烈的个人色彩。thoughtwork并不是敏捷管理的代表。这里不评价thoughtwork企业的人,但有一点是可以肯定的,无论作者喜不喜欢,作为实践者,我认为敏捷是成功的,现实的。

    希望作者淡化强烈的个人喜好色彩,实事求是的谈论敏捷。这才是科学的态度

  9. 云计算被很多人嗤之以鼻,更多的时候是因为他们自己很少用或者根本没有意识到云的存在。

    一个最简单的例子解释云:从整个互联网中搜索一个特定的字符串,需要多大的计算量与存储量?各位觉得自己的个人电脑有能力解决这个问题么?这是云计算在运算领域的一个例子。

    另外,如果在3台以上的机器使用过本地版RSS阅读器的人应当都会曾经沮丧过,在多个机器间,不但同步RSS种子树本身是一个困难,也很难维护你每个种子究竟阅读了哪些线索。而这些问题,都可以用 google reader 解决,这是云计算在存储领域的一个例子。

    实际上,基于Web 甚至基于IMAP 的邮件服务,都是典型的云存储例子。

    google ,更确切的说并不是一个搜索巨人,而是一个提供免费云计算服务的巨人。

  10. 忍不住对你的敏捷部分加以评论。敏捷是一个炒作概念,尤其是ThoughtWorks对这个概念进行“炒作”,这从某种角度讲确实是这样的。但我个人认为其炒作的还不够:

    第一、事务都是螺旋上升的,一种力的推动力无法实现螺旋并且上升。自我很容易处于一个相对舒适的环境并减少变化,这是人性使然无法改变(我也这样)。对于中国软件开发的话,有太多太多的舒适区域(比如领域特殊,技术独特,国情使然)。正是敏捷的冲击才使从业者开始从其实践开始进行思考。可能宣传敏捷的人也有误解,可能敏捷在中国确实存在种种问题。但力与力的结合就会造成变化,造成各方面的变化,敏捷也会受其影响,而且这种变化是符合意识的发展潮流的。也就是更多的开放,更多的思考,更多的否定。

    第二、在上面列到的很多东西我也深恶痛绝,比如SOA(疼痛指数5)。使我更感到难受的是大家对技术的误用和误解(疼痛指数10)。相比之下最让我愤怒的是没有一个相对官方的地方让我说出大家理解的偏差、厂商宣传的夸大、技术人员的悲催(疼痛指数100)。但敏捷不同,你如果觉得周末Open Party人少的话,可以到ThoughtWorks北京公司预定一个时间,并邀请其他“敏捷”人士参加。大家互相讨论(记得叫上我),我相信这会更加冲击我们的思维与意识。这又将是一次敏捷的炒作 ;)

    第三、ThoughtWorks的人,用我朋友的一句话是:充满激情的年轻人。我参互多了我也有深有同感,激情让人感到年轻,激情也可能使人错误连篇。但在激情之后的勇气是我感到最为珍惜的财富,这种勇气也同样感染我,使我内心充满了对软件的信心,对中国软件的信心,对自己的信心。我希望ThoughtWorks把这种激情、这种勇气、这种信心带给更多的人(绝非敏捷前面简单的实践,但可能会以敏捷实践开始)。这可能和“我会UML”一样自大,但你不多学点东西,怎么能知道之前我们的所作所为是不合时宜的呢?不多和几个人交流交流,怎么能知道别人想到一些自己忽略的地方、别人坚持了自己敷衍了事的地方呢?这同样也需要炒作。

    我比较感兴趣与你当面/IM聊聊,在blog上回复沟通带宽太低。

    1. 我觉得你把ThoughtWorks的公司文化和ThoughtWorks的咨询方式混为一谈了。如果你喜欢激情、勇气、信心,我相信你见过传销,那种传销公司的文化同样可以更能带来激情、勇气和信心。对不起,这并不能代表其不是炒作的原因。

      个人的内心的激情、勇气、信心可以来源于自我的精神暗示,但是公司的激情、勇气、信心应该来源于其成就,而不是鼓吹

  11. 关于TDD
    效率确实并不如吹嘘的那样,一个是对个人的能力要求太高(最好是有测试专业的经验),另外,也证明了程序员是比较差的“观众”。

  12. TDD看起来确实很美,但能真正贯彻的公司真是少之又少,即便是我所在的所谓的500强…

  13. www :
    @kentwei
    别拿potian出来说事,认识牛人不代表自己牛逼,什么玩意

    沟通、简单、反馈、勇气。 敏捷的四大准则你一无所有。 另外,个人给敏捷加了一准则:感恩。

    施主,您眼中处处都是屎。

    高下立见嘛

  14. @www
    难怪程序员在别人眼里都是难以沟通、自以为是的科学怪人,连骂街都了无新意、干木疵咧的。

  15. Pingback: 如何学好C语言
  16. Java是Write once debug everywhere。
    说Java能靠虚拟机实现跨平台是个彻头彻尾的骗局,Java虚拟机本身就是个平台,偏偏又不是一个完整的计算机系统平台,靠和其它平台XXOO才能体现出一些平台中立性。

  17. XML 是个好东西,我刚开始也非常讨厌那个东西,人去读太难度都了,特别是作为配置文件的时候。作为数据储存又比平文件大。但是有了xmlspy这个工具之后,你会觉得看xml文件一点也不累,非常方便。相同的内容,虽然比平文件大,但是易读性大大增强。至少知道每个数据段表示什么意思,如果是平文件还得去数长度,在什么地方出现。像我是做EAI的,几乎所有的EAI工具都用xml作为文件载体,为什么,就是增强数据的易读性。在人和机器之间取得一个平衡。

  18. 一个技术的出现是为了解决问题,不能老眼光去看待新东西,新的东西出现必然是为了解决旧有体系存在的问题。web-service的出现是为了解决集成问题,软件行业发展到现在这个程度,一个企业必定存在多套系统,为了业务也好,为了避免信息孤岛也好,有时候需要在不同系统直接同步数据,比如从人事系统中获取员工信息。不同的系统,很可能用不同的语言开发的,比如你用c, 我java,他用.net,web-service的出现是为了解决connection问题。

回复 chaser.chen 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注