首页 > 技术读物, 杂项资源, 流程方法, 编程工具 > 那些炒作过度的技术和概念

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

2011年1月28日 发表评论 阅读评论 39,028 人阅读    

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微信公众账号

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

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (25 人打了分,平均分: 4.24 )
Loading...
  1. 2013年11月15日10:01 | #1

    cloud绝对over了,其实不过就是分布式的那一套,进程调度,大规模并行计算,通信,认证权限审查

  2. ZnForce
    2014年11月7日15:09 | #2

    浏览博客链进来的,一看时间也是一年前的了。也差不多在14年初的时候团队使用了所谓的敏捷,例会、计划扑克、讨论等等形式上的样样都做了,但是感觉跟理论上的相差甚远,甚至变成了绩效的工具。设计、测试、文档、等等都草草带过。只能说当时所在的公司用了敏捷正好给自己的混乱的项目管理有了个支持的方法论。就如上面有的回复所说的,敏捷可能也是得跟团队的管理水平相对的,差的用了所谓的敏捷也改变不了太多。

  3. knull
    2015年4月17日16:05 | #3

    看了这么多的回复,我忍不住也来说两句,关于敏捷的。
    首先,我个人不懂“敏捷”,虽然参加过两个敏捷项目,主要是华为的。
    所以,我对敏捷的观点,仅仅是针对华为敏捷。
    华为敏捷,给的最大的感觉,就是教条主义太严重了。大家仅仅是在那喊口号,教条化运作。但是,真正理解敏捷的人(在我项目中),我是没看到。最懂敏捷的,不是我们开发、项目经理,而是我们的QA——一个不开发的人。这是明显的教条主义。

  4. ppcai
    2016年1月5日16:46 | #4

    其实人活着,靠本能反应,神经反射事最滋润的,因为你不需要懂脑子,而那些懂脑子的都是少数人,而这些少数人才是推懂社会进步的动因,而这个世界又有几个人愿意或则能够理解爱因斯坦的相对论呢,写代码嘛,靠本能也是够的,至于效率和效果还是留给少熟人取操心吧,毕竟大部分人是靠本能活的,怀疑和验证二者缺一不可,不实践就没有发言权,不在一个层次实践就不要在那个层次怀疑,井中望月的境况也是让人理解的。发现问题并解决它才是有意义的,发现问题抱怨它是无意义的,摸着石头过活被大水冲没了也好过站在孤岛上饿死要好,嘲笑那些以实际行动试图过水拜托困境的人就更为可笑,这是十足的负能量。

  5. none
    2016年3月26日18:35 | #5

    太复杂了,玩真累!

  6. sqr
    2016年3月29日15:27 | #6

    这些分析我大部分认同,作者不是说这些技术完全虚假,或者无用,只是说普适性没有那么强。我做过几年scrum master, 也看到agile的实践带来的分工合作方面的进步,无论队伍内部还是与客户之间的交流,但这不是万能的,看你遇到什么项目,周期多长,需求是否明确,能否把任务细分,能否迭代,是否有相关工具的支持,甚至是否有领导跟客户的支持。即使实践,用出好处也要1,2年磨合。

    这很多问题我觉得也源于太多人热衷于管理,没写过几天程序,就目标明确的要做管理,做咨询;实际动手的人地位低,意见被轻视。发号施令的人心虚,只好讲大话废话,玩概念,最后很多技术就这么流行起来的。

  7. 2016年5月25日19:23 | #7

    Java两次让我失望
    一次是买安卓手机 心想“反正有虚拟机” 就入了X86的(然后我就不说了)
    再一次是玩我的世界 心想”不就几个方块怎么可能会吃配置”(然后我也什么都不说了)

评论分页
1 3 4 5 3609
  1. 2013年8月10日16:27 | #1
  2. 2013年8月24日19:44 | #2
  3. 2013年11月2日16:14 | #3
  4. 2013年12月2日11:30 | #4
  5. 2013年12月5日03:35 | #5
  6. 2013年12月9日00:10 | #6
  7. 2014年1月2日14:03 | #7
  8. 2014年1月19日13:45 | #8
  9. 2014年2月6日22:48 | #9
  10. 2014年2月11日20:25 | #10
  11. 2014年2月14日10:23 | #11
  12. 2014年2月21日15:44 | #12
  13. 2014年2月22日23:46 | #13
  14. 2014年2月23日22:57 | #14
  15. 2014年3月8日00:20 | #15
  16. 2014年3月8日16:46 | #16
  17. 2014年3月8日22:20 | #17
  18. 2014年3月10日20:17 | #18
  19. 2014年3月20日10:59 | #19
  20. 2014年4月1日11:44 | #20
  21. 2014年4月14日14:17 | #21
  22. 2014年4月19日21:46 | #22
  23. 2014年5月12日18:27 | #23
  24. 2014年5月27日22:15 | #24
  25. 2014年5月30日14:08 | #25
  26. 2014年6月15日22:34 | #26
  27. 2014年8月11日22:19 | #27
  28. 2014年8月22日20:17 | #28
  29. 2014年9月4日22:44 | #29
  30. 2014年9月14日15:36 | #30
  31. 2014年10月1日10:50 | #31
  32. 2014年12月30日18:30 | #32
  33. 2015年3月14日10:31 | #33
  34. 2015年3月16日15:14 | #34
  35. 2015年3月24日15:57 | #35
  36. 2015年3月25日08:44 | #36
  37. 2015年3月25日08:49 | #37
  38. 2015年9月7日12:37 | #38
  39. 2015年10月9日18:09 | #39
  40. 2015年11月23日11:54 | #40
  41. 2015年11月25日01:31 | #41
  42. 2016年4月19日18:04 | #42
  43. 2016年5月11日08:24 | #43