谈谈如何推进自己的技术主张

这是我参与更文挑战的第2天，活动详情查看： 更文挑战

充分的技术调研

首先你应该做充分的准备工作，对一个框架或技术尽可能多的了解或理解，并且一些问题要想到别人前面，这样可以增加别人对你的信任。

谈到了解或理解一个框架或技术，你至少要知道：

• 这个框架的诞生背景是什么，或者它主要解决什么问题？
• 它的主要原理是什么？
• 整个框架的结构是什么？（比如vue：三大块：script、style、template）
• 基于该框架的项目组织架构是什么样的？

以上几点比较基础，可通过阅读官方文档来了解（对于文档，你应该抽时间全部看完，可以有选择地看，但一定是看完的）。

看完后，你还应该动手写一些Demo，上手感受一下框架的开发感受，Demo应该不过于简单亦不过于复杂，要很好地还原一些常见的业务功能点。

最后，如果有条件，你还应该阅读一些关键模块的源码，理解核心模块的实现原理，这样你在讲述时会底气会更足。

用数据衡量潜在的效益

光有技术调研本身还不够，还需要结合项目业务特点，指出该框架或技术能给团队带来哪些潜在的收益以及风险点，毕竟编程的世界里是没有银弹的。

比如强调它带来的好处：

• 降低开发成本30%（如果给出数据，需要解释这个数据是怎么来的？）
• 提升了开发体验（提高了编译打包速度，热更新啊），开发心情好了，代码质量提高，bug减少
• 良好的生态（丰富组件库啊、第三方的类库啊等等），基本满足大多数应用场景
• ...

但也要考虑一些风险点：

• 项目里引入该框架的成本有多大，有没有额外的风险？
• 项目里已有功能该框架能否很好地支持？
• 在未来该框架能否很好的适应业务的发展？
• ...

两个方面都要尽可能地仔细考虑，做到心里有数。一旦别人问到了一个你忽略的重大问题，你就会变得很被动，所以核心问题一定要认真核对。

当然你的目的是推荐，所以应该突出技术本身的优点，认真解答其他同事的疑惑或顾虑（风险或缺点）。

你提出的潜在效益越多越真实越准备，你的论点就越具有说服力！

站在别人的角度思考问题

准备完资料，有一个很重要的点你需要特别注意，就是沟通。

无论你的准备多充分，推荐的技术会多大程度地造福团队，你都不要认为一切应该水到渠成。不要有任何的心理预设：这个事情，领导应该支持，不支持的人就是傻逼，之类的。

相反，我们应该站在对方的角度思考问题，问自己：他更在乎的是什么？（这里主要是指领导）

开放性话题：面对新技术，领导更在乎什么？

• 稳定性（框架比较底层，万一不稳定，有严重issue，这可都是领导背锅的）
• 在未来一段时间内能否很好的支撑业务（如果将来公司业务重心发生了偏移或者其他的变动，这种技术革新还有多大的价值呢？）
• 迁移或应用成本（只有在抛去成本依然有显著的收益时领导才感兴趣，因为那样才算创造了价值）
• 采用新技术后能给团队带来多大的收益（开发效率是否提升？开发质量是否提高？ 没有比节省时间更有价值的了）

以上是我的观点，你认为呢？（可以在文末留言哦）

当然，还有你的同事，他们可能也会参加你的推荐会，也是一样的道理。

所以，我们通过站在别人的角度上思考问题，拉近双方的距离，郑重地考虑一些别人关注地现实问题，会让沟通变得更顺畅。

最后，别人可能也会提出一些问题，一定要认真客气地回答。如果别人对你的讲述有误解，切忌表现出轻蔑或不耐烦的口气，无论是你还是他的问题，现实是你的观点没有很好地传递给他，我们可以尝试换种方式再说一次。

牢记自己的目的：推荐自己的主张。

讲讲我的一次失败的经历

当然公司使用游戏引擎egret制作产品的某个模块，团队采用了一个开源的框架，基于这个框架做了一些封装，几个迭代下来，大家苦不堪言。

后来熟悉这个框架并做了几次迭代后，我总结了一些问题，尝试加班加点做了一个更加轻量的框架（说框架，我更愿意称他为App应用toolkit），封装了一些基础代码，提供了路由、组件等模块。代码只有几百行，相比之前的框架轻量了N倍。

在解决了一些bug后，我尝试用这个东西开发一部分业务功能，无论效率和质量方面都有很明显的提升，于是我很有信心，介绍给其中一个同事，得到了肯定的回答后，我组织了会议打算将它推荐给团队：

• 提供了路由模块。以前应用只能一步步地往下走，现在有了路由，可以通过路由定位到业务模块（提效，职责更加的清晰）
• 封装了App层，源头指定两种容器：canvas和html。以前都是随便写，很容易出现干扰的情况，现在在源头实现了视图分层
• 封装了组件模块，组件可以全局共享。以前组件只能在特定的单元内共享。导致需要人工复制多个拷贝到不同的单元，当多人协作时带来了很大的维护负担和同步成本
• 代码更精简，更少的代码实现了相同的业务

无论是当时还是现在，我都认为我写的这个框架更加符合公司的业务场景，相比现有的框架更加优秀。然后最终结果是，领导并没有同意采用我写的东西，虽然他表示很欣赏我的设计和想法。

当时我特别不解，并且心里非常不服气。其实大可不必：领导有他的考虑，毕竟这是一个新的东西，稳定性和可靠性都是未知的，一旦出现严重问题，那后果是很可怕。

如果再给我一次机会，我会多费点心思跟领导多一些沟通，通过一些行动去证明：多写一些测试用例啊，写一些对比代码啊，多一点耐心、多一点坚持，也许结果会不一样，谁知道呢?

后来也做过一些技术的布道之类的，有成功的，也有失败的。一旦心态摆平了，把该做的工作都做了，结果什么就显得没那么重要了

最后

最后，感谢阅读，如果本文对你有所帮助，欢迎点赞或转发给其他人哦，如果有任何的疑惑，也欢迎留言讨论哦，谢谢！