每个技术人员都会有技术情结，这次我们来聊聊它

每个技术人员都会有技术情结，或多或少而已，语言情结，框架情结等，这篇文章就来说说自己的技术情结和看到的一些人的技术情结的事。

我自己对OSGi算是有情结的吧，很多年前在上海工作的时候，偶尔会去参加一些meetup，看着讲topic的人都觉得好牛，好想认识下，但相对还是会比较困难，直到我接触OSGi，并且写了一些普及的文档后，很快就认识了不少业界的人，这些交际很大程度还影响到了我之后的职业生涯。

在07年加入阿里后，所做的工作其实和OSGi没有任何关系，自己甚至也觉得不会再和OSGi有任何关系了，但所谓的情结必须说就是深入骨髓的，到09年自己所负责的产品出现class不隔离导致的一些问题后，就立刻想着引入OSGi，这个决定可以说和情结有很大的关系，把自己最熟悉、最喜欢的一个东西放到商业级的产品中，这我想是很多情结最后最好的输出吧，当时为了给自己找到充分的理由，就把动态化也写为了需求的重点，class隔离+动态化，那绝对是OSGi的完美场景，于是整个团队在这件事上扑腾了好几个月，OSGi是引入了，动态化最后放弃了（实在太复杂，对于有状态的class要做到动态化实在太麻烦，而且在集群化的背景下其实意义不大），团队成员为了熟悉OSGi的开发模式花费了巨大的精力，并且以后加入团队的人也都受到不小的困扰，在那次折腾后，尽管看似情结输出了，但从此以后几乎所有来问我做插件化、class隔离等方案的选择时，我基本都会告诉他们不要用OSGi。

从OSGi情结这件事后，我就再也没有把情结和工作严格绑定了，情结能输出到工作最好，不能输出也OK。

在工作的历程中，也还看到其他很多类似的case，例如框架情结的同学，有些时候很容易做出决定是在自己所做的东西中要使用某框架，而也许公司内其实有类似的产品，并且有专职团队的维护和支持，说到这个必须说说以前经历的一个case是有一个同学对MongoDB非常有情结，于是在自己的一个产品中就引入了MongoDB，但其实自己对MongoDB的细节并不算非常清楚，结果后来运行过程中出问题了无法处理，而且其实后来review方案会发现在该场景中MySQL完全就可以满足；又例如语言情结的同学，有时候很容易做出决定是在自己所做的东西中使用某语言，而完全不顾及整个公司可能没太有这方面的人才，以后这东西还能不能维护得下去，说到这个可以说说火热的node.js，情况也类似，在运行过程中出现问题，没人能处理，只能临时Google等，搞得非常被动。

其实有技术情结不是坏事，反而多数是对技术有热情的人才会有技术情结吧，但技术情结是否要落到工作中，这个就必须深思熟虑了，工作其实是工程化的东西，工程化要考虑的因素非常的多，例如框架是否有专职团队支撑，未来的可维护性和持续发展性，甚至是业界的人才状况等都要考虑，所以很多时候语言的争论什么的其实意义不大，当然纯技术层面的讨论OK。

你会有什么技术情结呢，会不会有无论如何都得把情结输出到工作中的想法，或者你看到过什么现象，经历过什么故事，来回复说说看。

更多深度技术内容，请关注云栖社区微信公众号：yunqiinsight。