有位老兄写了一篇《被高估的几种it技术》，大部分都没意见，只是对于其中xml, oop, 云计算、web service，敏捷开发几项，感觉应该客观地再评价一下。
xml
xml有其他数据语义标准之长，而无之短，只是语法上上有点儿冗余，但是这东西主要还是让计算机看的，捎待让人看懂已经很不错了。如果你玩过银行里那种古系统中的文本文件数据报文你就知道xml的好了。xml还有一整套配套的技术，如xmldoc, xpath等辅助使用。
我见过用字符串拼接、查找来生成xml或是解析xml的（好可怜的程序员），这种用法是在用xml的皮毛，如果你是这样的程序员之一，那快去系统学习一下吧！不然要累毙了。
oop
原作者认为oop的设计模式把程序开发搞复杂志了，实际上oop与设计模式不是一回事，oop的思想根本上是把现实世界在计算机中建立映射，这是很好很有效的降低开发复杂度的办法。设计模式是是在oop基础上的算法总结，是指导而非要求。要反对的是学院派由于《设计模式》一书的存在而“过度设计”，而非是oop本身。但是，当你系统扩展弹性要求高了之后，你会发现答案还是设计模式中的一些办法。
我没有看过《设计模式》之前，多年做oop的开发，之间为了解决问题而想出了不少设计办法。后来为了不被学院派精神虐待而看了《设计模式》这本当年的“圣经”之后，发现其中大半的设计办法我早就在之前的工作中自行发明使用过了。
web service
web service是目前最好的解决平台间数据通讯的技术了。中立的数据类型，支持对象的语法规则，中立的通讯协议，自动代理方法工具，甚至连异常都能跨平台传输，你还需要啥呢？
不过，它的确不是万用法宝，它只能解决他适合解决的问题。ibm最会炒概念，你迷信ibm是你无知, webservice仍然工作得让人安心。
最后，要是如果能解决web service的接口版本的兼容性问题就更好了，不解释了，用过的就知道我的意思。
敏捷开发
敏捷开发的一个潜台词是“高手开发”，“敏捷” 的核心就是：深刻理解业务需求 + 合适（成本、可扩展性的均衡）地实现需求+ 一有必要立即重构以增加设计弹性 + tdd（质量保证）。所有这一切都需要高手才能做到。关于双人编程，实践中发有两个巨大好处: 一、知识传承没有问题了。二、两个人一起工作，注意能高度集中几倍于单人工作时的时间，三，讨论能理清思路。
“敏捷”中文档的问题：同步程序与文档是一件很麻烦而没有效果的事情，后来人一般不会看详细设计的文档，更别提你的文笔也不一定达到让人能轻松读下去的水平。我的解决办法是：
一：设计文档就到架构设计。说明程序结构、设计思路、数据库设计，聪明人看过之后就明白你的意思了，一般不需要更详细的文档了。
一：程序就是文档，我不在乎你的变量名有多长：匈牙利命名法 、动词短语方法名。后来人看你的程序要像看一篇文章那么清楚。
二：文档注释，必要的过程＼算法＼注释对接口方法进行说明。然后ndoc之类的工具就可以生成文档了，比自己搞得好得多，而且不会出错。
对于大型的系统，我的实践经验是：在架构设计层面（系统设计、程序结构设计、数据库设计等），高手进行“敏捷式设计”，而具体的实现可由普通开发人员完成，一则提供优秀的系统设计、为未来始终留下扩展余地，二来也不会过度设计导致实现成本过高，三来普通的开发人员的工作也好干。
题外话：与高手一起工作的惬意无与伦比。
云计算
其实这是一个基础运行体系的解决方案，在专业it运行领域，虚拟化、基于冗余思想的高可用硬件是多年以来企业级厂商努力的方向。
虚拟化有两个方向，一个是把一个高性能的硬件分为多个虚拟机运行，如ibm的高端机型，另一个方向是把多个物理机整合为一个虚拟的单一机器，任务分散、分布执行，从而得到高性能计算能力。
云的意思是两者的结合——多个物理机整合为一个虚拟机，这个一个虚拟机上再分为多个独立的逻辑单位，用于隔离不同的应用程序运行空间。这样，即得到了应用程序管理的便利，又得到了冗余硬件的可靠性，以及高弹性的性能管理。只要你做过基础运维你就会理解这个东西的宝贵。
一个IT经理高声呼喊，快点到来吧，云计算！我需要一个私有云来解放我！