关于引入新技术与模式的思考

在如今这个快速变化的时代，无论是技术还是开发流程，都无时无刻不在变化之中。如果不能紧跟潮流，拥抱变化，那么无疑会被时代所抛弃。可是很多时候我们开开心心、充满希望的引入新的技术或者模式，却引发各种问题，最后不得不倒退回到原来的模式当中。

那么为什么会出现这种问题呢？我认为归根结底还是两点原因导致的：

1. 对于新技术或新模式可能遇到的困难估计不足
2. 执行力不够强

关于第一条，很多时候在我们的项目过程中会遇到一些问题，比如代码不规范，质量较差，耦合度高、需求反复更改等。这些问题会降低我们的效率，拖后我们的进度。于是自然而然的，我们会想办法去解决这些问题。我们在网上找答案、在各种会议上听其他公司的分享，最终引进了新的技术体系或开发模式，比如进敏捷开发、DevOps、微服务架构等等。这些新方案的确会在很大程度上解决之前的问题，然而天下没有免费的午餐，它们在解决原有问题的同时，将不可避免的引入新的问题。最显著的一点就是，越是“高级”的解决方案，它的复杂度就越高，光是应对这些复杂度，团队可能就要付出很大精力。当外界去宣传这些新的模式和概念的时候，讲的也都是它们的优点，这其实很好理解，因为既然是被很多人推崇的新模式，那么它必然有很多原来的模式所不能比拟的优点。但是决定新模式引入成功与否的，恰恰是我们能不能清楚的认识到它们可能会带来的困难。要知道，在软件开发的道路上，其实并没有银弹，只有了解新模式会带来的困难，并且有应对之道，才能从中享受好处而不是引火烧身。

而第二点则更考验团队中的人。比如在团队大力宣扬敏捷开发的人是真的“敏捷大师”，还是只是有点了解的“半瓶子醋”；比如我们在执行一些流程的时候是真的理解了这些流程的精髓，明白它们的好处，并且根据实际情况能灵活变化，还是只是照猫画虎，照搬套路？不论是leader还是团队中的其他成员，对于新模式理解的深刻程度基本上也决定了这次引入的成败。除了对新模式的理解之外，团队人员的素质也很重要。这里说的素质，不单单是专业方向的技术能力，还包括团队内外的沟通、交流、协调等等一系列的软实力，团队内部技术、非技术上的积累非常重要。不论模式多么新颖、方法多么牛x，最终执行的还是人。好的模式可以使强大的团队变得更强大，但不能把小白瞬间升级成老司机，如果指望一个连单元测试都不会写的团队瞬间精通DevOps，无异于痴人说梦。饭要一口一口吃，路要一步一步走，如果一步跨太大，容易扯到裆。

最终，当我们要搞新东西时，需要考虑：

1. 当前的技术或流程存在什么问题？
2. 如何解决这些问题？
3. 是否必须引入新的解决方案不可（从当前和发展的角度看）？
4. 新的解决方案能否解决这些问题，如何解决（是否适合当前的环境）？
5. 新的解决方案会遇到那些问题与困难？
6. 我们的团队能否解决这些新引入的问题？
7. 用什么方法解决这些新引入的问题？
8. 需要多长时间能解决？
9. 需要付出多大的代价？能否承受，是否值得？

当这些问题都想清楚了，那么在执行这些新的方案时就不会手忙脚乱。引入新的解决方案时，最重要的不是看它的优点（因为它当然有很多优点，要不然怎么会很火），而是能看清它的缺点。当然，我们不可能在一开始就想到所有可能存在的问题，在具体实施时还要根据当时的状况进行灵活的改变，但提前考虑好这些因素，做到心中有数，就不会觉得新的路上处处是坑了。