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

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

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. 谢谢分享,大部分还是蛮认同的。可能每个人看到的视角是不同的,有一个不认同的是cloud computing,这个现在已经落地开花了,不是炒作了。当然如果认为chrome和EC2就是cloud computing,那就有时偏颇。还有越来越多的应用都已经cloud了,比如salesforce.com, email的hosting,还有virtual private cloud等等,实质性的东西越来越多了,不过国内对这方面的接受度还不够。

  2. simple只是说它能传输的东西是“简单的”,又没有说它本身是简单的……

  3. 有些东西不太认同,可能大家领域不同。
    我所在的环境,Web Services已经是唯一的交互标准,规范很复杂,但是一般人不用太关心,底层都封装好了。
    没赶上过CORBA炒作的年代,这玩意现在没人关心,但是正在底层默默的工作着。

  4. sharepoint 对用户来说,和office 集成是非常的方便的.
    对管理和维护,以及DR,那就是一场恶梦.

  5. 我认为UML是很好的东西,在国内是没有多少人用,因为大部分programmer很少去设计就去编码。在国外的情况是很多人用的太多用的太泛滥了,跟国内相反。UML可以将设计思路落实,有文档可查。

  6. 大部分基本还是赞同的。不过还是觉得有点过激了,博主所说的是国内的情况。其实像UML,XML,OOP这些东西都还是好东西的,只是国内很多人一窝蜂式的盲目使用,就变得恶心了。没有什么东西是只有优点没有缺点的,关键看使用的方法,合理的使用把他们的优势充分体现出来,我觉得博主所说的东西里面大部分还是很有价值的。当然,被炒作过度那也是事实,它们没那么神乎其神。

  7. 专门冒泡顶一个。对Thoughworks了解不多,但时常阅读Thoughtworks某名人的博客给我的感觉,的确如文中作者所言:“他们信仰敏捷流程的已经接近宗教信仰,他们的精神世界很朝鲜。”

  8. 关于ThoughtWorks那段,想知道作者是真实了解过他们的情况,还是单从博客或口头交谈中获得的信息?如果没有实际接触过,这么说是不是有失偏颇?我并不是替ThoughtWorks辩护什么。每年都参加敏捷大会,从第一届开始就有参与。不管怎样,在中国敏捷被大家认识,TW的宣传个人认为是很关键的因素。

  9. 关于ThoughtWorks那段,想知道作者是真实了解过他们的情况,还是单从博客或口头交谈中获得的信息?如果没有实际接触过,这么说是不是有失偏颇?我并不是替ThoughtWorks辩护什么。每年都参加敏捷大会,从第一届开始就有参与。不管怎样,在中国敏捷被大家认识,TW的宣传个人认为是很关键的因素。

  10. 关于ThoughtWorks那段,想知道作者是真实了解过他们的情况,还是单从博客或口头交谈中获得的信息?如果没有实际接触过,这么说是不是有失偏颇?我并不是替ThoughtWorks辩护什么。每年都参加敏捷大会,从第一届开始就有参与。不管怎样,在中国敏捷被大家认识,TW的宣传个人认为是很关键的因素。也曾跟公司一起去TW办公室参观过,他们现场的工作蛮給力的说,项目很多,对敏捷的实践是我接触过的公司中坚持的最好的一家。别以为我是拖,只是希望提观点的时候应该有事实依据。

  11. 关于ThoughtWorks那段,想知道作者是真实了解过他们的情况,还是单从博客或口头交谈中获得的信息?如果没有实际接触过,这么说是不是有失偏颇?我并不是替ThoughtWorks辩护什么。每年都参加敏捷大会,从第一届开始就有参与。不管怎样,在中国敏捷被大家认识,TW的宣传个人认为是很关键的因素。也曾跟公司一起去TW办公室参观过,他们现场的工作蛮給力的说,项目很多,对敏捷的实践是我接触过的公司中坚持的最好的一家。别以为我是拖,只是希望提观点的时候应该有事实依据。@游侠之心

    1. 对不起,服务器性能问题,让你留言留了那么多遍,不好意思。重复的留我已删了。

      关于ThoughtWorks那段,我也去过他们在东直门的公司,也认识不少的人,有一些咨询师,有开发人员,还有PM,还有HR,他们的人员流失也不小,原因是他们没有足够有意思的项目来满足这些人。当然也有别的原因,就是中国的业务停滞不前,连HR也走了。

      下次你去他们办公室,还有在他们的大会上,问问他们在中国做了什么项目。(注意,咨询师的侃功是很厉害的,你要细化他们的神侃中的那些细节)

  12. 作为局外人,我也很想了解一下楼主对ThoughtWorks有多少了解。我看过一些ThoughtWorks人的著作,也认识一些ThoughtWorks的朋友。我所知道的是其实ThoughtWorks内部咨询师是占少数的,大部分人都是在做项目,而这些咨询师也是在公司的项目里锻炼了几年才能走出去的,说他们的咨询师没写过代码这点我实在不能认同,所以觉得楼主所说的有失偏颇。
    当然,我觉得作为咨询师有些事情肯定要占一些“忽悠”成分,这个你不能否认吧,但如果这些实践是好的,能够帮助别人那就算是忽悠的结果又有什么不好呢。

    而且,我所认识的ThoughtWorks朋友都很少将敏捷挂在嘴边,倒是常常将一些最佳实践挂在嘴边。

    1. 我所知道的那些ThoughtWorks的Blogger和和几人有名的咨询师都是缺乏项目经验的。至少有一个人连代码都没有写过,然后整天地向我灌输怎么样才成写出好的代码(我就不点名了)。而那些做项目的程序员,他们整天和我说TDD如何如何好,和我说Design Pattern如何如何好,持续集成如何好,开口闭口就是我们的项目不需要文档,代码就是文档。结果,仔细一聊,连C++的虚析构函数和虚继承的目的都搞不清楚。后来才知道是个Java程序员,找Java程序员来给C++ 程序员做指导,我真是无语了。最令人夸张的是,当他们在Review代码的过程中,提得最多的建议是——为什么没有Unit Test Case,为什么没有用Design Pattern,而从来不管最重要的——有没有实现需求。我不是说敏捷不好,在原文里,我说了其实其中还是很不错的Practice的,只是中国的ThoughtWorks太过宗教式地过度地炒作了敏捷。

      我在文中提到了,只有适合自己的才是Best,不是你的Best Practice就一定是我的Best Practice,巴西足球的的Best Practice绝对对德国足球队来说是恶梦。我给ThoughtWorks的建议也在文中提到了——多分析项目和多听听项目中的人,而不是一味的灌输所谓的Best Practice。否则,那就是电视购物。好的裁缝不是让每个人都穿同一款式的衣服的,而是要做到真正的量体裁衣,每个人的衣着一定都是适合自己的体型和风格的

  13. 很多东西我觉得不是炒作的过渡,而是我们没有真正领会他们,或者说他们的时代还没有真正到来。比如web2.0,N年前就有web2.0的概念,也说网络要社区化,但twritter, facebook这类划时代(姑且认为他们划时代吧)的网站出现时,我们才有真正的领悟,想想这个经历有多久?再举一个云计算的例子,IaaS, PaaS, BPaaS,现在正在一步一步的实现。你可以看看saleforce.com,会不会真的为中小企业带来效益?对于云计算,如何商业运作与技术相结合,这个需要人摸索与实践,云时代还没有来而已,但很快了。SOA一类的也是如此

  14. 楼主太偏颇了。
    同意楼上的,云时代正在一步步来临。云计算的应用不仅仅局限于google和amazon所推广的领域。博主有点将自己看到的当成大多数了。

  15. 解释一下,关于云计算,在写下这篇文章的时候我本来有点拿不准主意,后来想了一下,回顾了一下历史,如COM啊,ActiveX啊,EJB啊,感觉都是很强的东西,但是最终也只是被炒作的。云计算,我不知道未来怎么样,从今天来看,这项技术在今天存在炒作的情况——中移动云,阿里云,到处都是云,在云面前,神马都是浮云了。

  16. >>>流程这个东西,应该是项目组自发出来的东西,而不是被 灌输,被教条使用的东西。不同的团队、不同的项目、不同的人,不同的风格就是不同的流程,只有去使用适合自己的流程才是最好的流程
    呵呵,偏激了。项目组自发出来的东西,未必就是好的东西。适合自己的流程,不见得就是好的流程。存在的有其合理的解释,但不一定就是最好的东西。就像中国的官僚。
    敏捷开发有一套系统的实践和理论,有工具方法,值得大家去学习,借鉴。而不应该因为有商业咨询公司的存在,就否定敏捷开发。

    1. 你理解错了!

      其一、无论什么样的流程,都是一种需要持继不断完善的过程。自发出来的东西不一定是好的东西。但是你需要让这个项目组去自我进化他最合适的东西。问题不在于他自发的东西,问题在于他是否发问题而去进化。不要去灌输,不要是去为项目主作主,不要成为“敏捷控”。

      其二、我说了这世界上没有完全好的东西,任何东西都有他的光明的一面,也有他黑暗的一面。敏捷过程也有他阴暗的一面。完全好的东西,只出现在电视购物和新闻联播 中。所以,适合自己的才是最好的。不是任何人都适合敏捷的,就像不是任何人都有运动的天赋

      其三、敏捷开发有他的好的地方,这点我在原文中也承认过。他的炒作原因我也说得很清楚了——咨询师的问题,不理解用户的问题,只关注敏捷的问题,洗脑的问题。等等。敏捷这种推广方式,就像当年的马克思到处推广共产主义的方式

      其四、我批评的是咨询公司推广敏捷开发的方式和炒作无异。

      P.S.,你的主页很有宗教样子。

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

  18. OOP最重要的不是Design Pattern,而是对复杂问题的分解,如果你没写过相当数量的代码,没有一个顿悟的过程,你是理解不了的。

  19. 这篇帖子才是企图过度炒作的对象。。。

    楼主对很多概念理解的不够深刻或明显处于望文生义和人云亦云的阶段。

    比如SOA吧,可以说大多数人每天做的东西就是SOA,只是一般人没有能力或精力将其理论化而已。至于说用了SOA就离不开IBM,简直就是滑天下之大稽。SOA不是几个理论家凭空想象的东西,是无数实践中总结出来的,它是系统构建的指导思想,不是具体的技术,楼主想的太简单了。

  20. 不知道的我就妄加评论了,但是云计算要看是什么云了,如果是私有云还是有很大前景的。

  21. 别的我就不说了,我都基本同意楼主
    我只说敏捷的部分,楼主加红加粗的那段对流程的理解,恰恰才是真正的敏捷,国内很多人都理解错了,可能是一些教练的误导,也可能是大家一厢情愿的理解

    1. “楼主加红加粗的那段对流程的理解,恰恰才是真正的敏捷”,太正点了。这和那些中国ThoughtWorks的人何其相似啊,当你问他们为什么我在实践敏捷的时候不是很舒服,他们通常会告诉你,你那不是真正的敏捷!呵呵。Again, 他们从来不会去理解你,他们只是在努力改变你,这就是宗教和洗脑。

      P.S. 你说的那些教练就是中国ThoughtWorks那些20出头的咨询师了。

  22. collshell大哥,您以往的博客中不一直信“XML”吗?和您列举的第3条违背吗?

  23. 很正确,就是这些感觉。但是,这只是每样技术的简评。

    其实深入里面,这个评价会更复杂。

    国内,国外爆炒各种概念主要是用来忽悠,用来谋取利益。具有决策地位的人往往并不了解各种纷纷攘攘的,一半是忽悠的技术,如果没有一个秉着科学和严谨态度的决策支持体制,很容易被忽悠的。

    这些用来忽悠的技术都是不能简单讲明白的技术,如果能很容易讲明白就没法忽悠了。

    不过往往被忽悠的人傻,钱多。所以紧跟这些方向还都能挣钱:)。

    还是Unix的设计的最好 – 简单就是美!不过另一方面来说,简单就是没钱,没GDP,没工作机会,再看看微软,这就是真实的世界!

    还是老祖宗说的好,面对复杂的情况要中庸,不可偏颇。

  24. XML:markup vs. data。data:XML Schema,syntax vs. semantics
    SOAP:meta-protocol
    ……
    傻逼永远是傻逼,精英终究是精英。楼主是明白人,多说无益。

  25. 楼主说的话很直率。还有用朝鲜精神做比喻也是很精彩。从我了解,博主所说的话基本属实。说实话,写程序的就踏踏实实干点有用的东西出来。一天到晚叫唤的,多半都是在扯淡。还有,如果是托就别喷了。我肯定的说博主说的话部分是可以被验证的。当然应该避免对于某些工司的过分攻击,但是适当的发表想法是对的。中国一大特点就是忽悠多

  26. 楼主说到我的心坎里了……………特别是对于xml和oo。那些Java的网站框架都是用XML做配置,累不累啊。一谈设计,就说OO,有没有想过OO是否合适啊你的项目特点啊。有时候在想,提出这些概念的人可能就是传说中的“太空架构师”,专门忽悠技术人员。

  27. “流程这个东西,应该是项目组自发出来的东西,而不是被 灌输,被教条使用的东西。不同的团队、不同的项目、不同的人,不同的风格就是不同的流程,只有去使用适合自己的流程才是最好的流程。” — 这恰恰是敏捷所倡导的。

    1. jnj,你理解可能有点误差。我所说的是项目组自发出来的东西可能还包括waterfall或银弹等非敏捷的东西。而TW中国咨询师们则是灌输和教条,就算是项目组自发,也应该在Agile的范围中。(举个例子,如果你告诉他们,项目组需要写很多文档,代码没有UT,与敏捷的practice背道而驰,他们会感到很难接受,而且还要和你争论半天)

      说白了,他们关注的只是敏捷本身,而不是项目和项目的中的人。

      另,敏捷的口头禅——
      1)当你说的有道理的时候,他们会说——这恰恰是敏捷所倡导的。
      2)当你实践敏捷有麻烦的时候,他们会说——这不是真正的敏捷。

  28. @陈皓

    敏捷方法和其他流程方法并不是相互排斥的,其实敏捷当中的迭代(iteration)就是waterfall,只不过周期更短,次数更频繁,目的是为了让用户尽早看到开发成果,及时获得用户的反馈。其他的概念如:测试驱动开发(TDD),例会(Standup),回顾(Retrospective),都是开发人员每天都在做的事情,并不是有敏捷方法以后才有的。

    如果谁在宣扬敏捷是银弹,或者除了敏捷方法外其他方法都不行,或者没有任何的项目经验就能够作为咨询师来指导客户的项目,我们是否应该搞清楚这是敏捷方法本身的问题?还是那些人有问题?

    1. 很好,开始进入——“敏捷是所有的一切”的论调了。这正我说宗教和电视购物的特征。就好像OO说的世间一切都对象,传教士说世间一切都是上帝创造的,马克思说的共产主义是一切。再这样下去——“神马都是浮云”了,未来还会出现敏捷的“两个凡是”和“四个坚持”,以及敏捷的“三个代表”。如果说敏捷什么都是,那就等于什么也没有说

      我的原文和回复中都在说,敏捷方法论是有其不错的地方,但没有所炒作的那么神(中国TW完全是在炒作这一方法论),任何东西都有好有不好的,适合自己团队的才是最好的,我不一定要写出质量高的代码,我只需要满足业务要求以有成功的商业模式就可以了,就好像意大利不一定要把足球踢得很华丽,1:0主义,难看是难看,但同样也能夺冠啊,因为适合自己。

      TW中国靠的就是炒作和灌输,他们不是一个咨询公司,而是一个来中国传教的某种宗教团体。他们的员工入职一年后就可以叫“高级咨深咨询师”,没有做过项目只用写写blog也可以叫“高级咨询师”,还有一个刚刚入职试用期都没有过,从来没有编过程,就可以在外面大谈如何能写好的程序。他们让更多的人也参与到了“教条主义”的行列,因为他们带来了那么多“条”可以去“教”

  29. 对敏捷开发的抨击很过瘾啊,实在是深入肺腑
    感觉不太喜欢TDD,程序员不喜欢处处受限制,而敏捷开发的循规蹈矩的流程,跟TDD的测试案例的限制,本质上殊途同归,结尾对TDD的赞誉,似乎有些自相矛盾。

  30. n年来,一直鼓吹一ini(即name=value)取代xml,现在终于。。。。。。。。
    不过,从分析的效率角度看,xml其实与json并没太多差别,都是层次存储的

  31. 只要特别指明一点,换个VM所有的程式都必须重新测试,就算小版本也是一样,尤其是牵扯UI的部份,Java’s Swing是个恶梦!
    另外,咨询师都是缺乏项目经验是常态,很多顾问公司都是这样的。

  32. @陈皓
    “还有一个刚刚入职试用期都没有过,从来没有编过程,就可以在外面大谈如何能写好的程序”
    这似乎是个人行为,因此推理到公司不靠铺,罪责安到公司身上,不合适吧。

  33. XML – 只是时候未到。语义网已经渐进的被实施和接受。搜索引擎是现在最广泛使用的机器人,它们理解数据的主要方式还是语义网技术,如micro-formats和micro-data,虽然不流行,但它还是未来。Tim Bray解释过json作为结构数据传输格会很成功,XML解决的不是这个问题,不过很大的问题在于XML被错误的被大量应用在这个场景下,成为反模式,这和XML技术无关。

    敏捷 - 敏捷不是过程。敏捷是轻量方法学,是重视持续交付价值的方法论。请不要把“敏捷过程改进”与“敏捷方法论”混谈。因为太多别有用心的公司(就是那几个靠中间件赚大钱的)开始把敏捷这个词过载,让它变成腐臭的词汇,所以这里被揪出来。可是现在敏捷宣言的签署者门自己也说只是这个词被用烂了,他们不会再称它“敏捷”了,那么就不要对着这个臭皮囊吐口水了。极限编程这样以“把最佳实践做到极致”的方法论,完全不是一个过程框架,它就是一个不断优化workflow的程序员最佳实践工具箱。看看《程序员的思维修炼:开发认知潜能的九堂课》这本书,反馈-改进的这种方式是学习认知的最佳方法。敏捷方法的一个共同点就是迭代,快速迭代交付让反馈-改进的周期加快,只是这些方法强调了不同的关注点。

    OOP - OOP最大的问题就是大部分人都没有学会OOA,不会分析就照猫画虎,结果设计出的代码很烂,然后就怪罪OOP,这多可悲?这些编程范型都是指抽象和设计的过程,而不是那些代码“看起来是什么样子”。不是有Class就是OO,不是有封装有继承就是OO。这个问题在FP里面一样,大部分人都不知道如何设计出函数,不知到如何写high order函数,不知到如何没有side effect,那样即使你使用了支持的FP语言写出的一样是过程化的代码。再退一步数,数据和算法过程大家都能设计好么?大部分做不好OOP和FP的程序员就能写出好的面向过程的代码?根本就不是编程范型没有掌握,而是编程的能力不够。看看《Clean code》,里面的提示大都是编程范型无关的。

    SOA我也迟保留态度,它只是被吹暴了,这个架构是很好的。

发表回复

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