class="p0">如果以Turbo C为起点回看这10几年的IT世界，就会发现每当新技术（C++,Java,OO,泛型,RAD,组件...）出来的时候，通常它会被认为是通解，而后在应用过程中才会逐渐发现它的限度。在这样一种过程中，我个人就逐渐形成了这样一种认知：对新技术而言，只有在不只知道它适合做什么，也知道它不适合做什么的时候，才算是真的掌握了它。在此之后才可能人驾驭技术，否则很容易出现技术驾驭人的情形。技术驾驭人是指由于狂热和盲信，无原则的维护某种技术，把A推上天堂，把B踩下地狱。常见的编程语言争执其实很可能是因为这个。
也就是说技术乃至方法论皆有其限度。导入新技术或新方法论时，最大的代价往往源于只见其利，不见其害。这点看似简单，但很容易被忘记。而被忘记的因由实际上可能有两个：
一个是（@aimingoo 提醒的）利害牵涉。历来有所谓屁股决定脑袋一说，这点在技术上同样存在，A公司介绍它自己的某项技术时，是不太可能去讲它的缺点的。理性评价与广告的区别就在于后者的一切说明是出于某种目的，而非是得到客观的结果。这类广告性质的宣讲杂入客观评价之中，最终就会导致你很难分辨那里是客观的，那里是扯淡的。
另一个应该是自己也没认识到。新技术这东西刚一出来，看到的都是种种新特性，种种好处，只有细用起来并反思才能发现具体的问题。OO刚出来的时候，估计很少人会去注意什么胶合层增厚问题，但逐渐就发现在解决问题时确实容易引入比较多的层次。
整体来看，认识新技术能干什么，要比认识它不能干什么更容易？后者其实是实践分享最应该解决的问题。所以从我个人角度看，如果个人或组织很系统的实践了某项技术，并想分享给社区，那最好在讲优点的同时，也能讲讲缺点，后面的价值更大。当然这很难是一种刚性约束，只能是一种呼吁，因为谁也不欠谁一个叫经验分享的东西。
为什么扯这样一个话题?实在是因为软件开发已经进入了一个选与自建并重的年代。开发富客户端程序的时候，顶天用用控件，很大一部分代码还是得自己搞定。而在今天，新技术框架层出不穷，SQL和NoSQL的选择甚至比某段代码的质量更关乎成败。抽象来讲，Tech Stack似乎决定了一种起跑的位置，选错了很可能先天就落后了。而更难的是在你进行选择前，你并不能靠一种传统的方法把所有技术都调查一下，打个分什么的。第一你未必有这个时间，第二即使你花得起时间，非长时间实践性的调查也只能得到很不精确的结论，这种结论往往不足以成为判断的依据。这事真的让人很痛苦。在这种时候，社区很重要，实践分享很重要。借助他们才能更好的认识新技术的限度：这也就回到本文的主题，看新技术的时候，不只要关注它能干什么，也要关注它不能干什么。
--------------------------------------------------------------
理想流 + 软件 = 《完美软件开发：方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质，追求真理。
相关文章
