项目转型撞上保守同事，怎么办

[Marstin]

去年年中加入现在的项目，当时是 java+jquery 一把梭，代码很多问题，很混乱，小组长和我及另一位同事一直试图改造整个项目，我这边主要负责的是前端的。

之前一直比较温和地推进，引入 require，限制全局变量，组件开发，制定编码规范等等方式，都还好，有的大家接受了，即便不接受，也不会明面上提出来。

最近我开始推 Vue 全家桶，webpack，mock，node 这一套后，几位同事的反应就非常抵触了。有说年纪大了，学不会了，有的说 node 太麻烦了。还有的说规范太多了，套路太多了，开发起来哪有以前简单容易。真的搞得我很心累。为了保证平稳过渡，之前我就已经在项目中用 CDN 方式引入 Vue 来使用，理论上来说已经能够适应 vue 的开发节奏了。至于 webpack，vue 那些东西我都已经全部配置好了，就只要执行一个 npm run dev 和 npm run build 命令就可以的，demo 我也写好了，看着 demo 就可以撸业务代码了，这难吗？？

为了兼容以前的项目，要放到老代码的 iframe 中，由 controller 访问，要放弃前端 router 做多页应用，还要按照 java 的打包逻辑打包到对应项目，真的搞得我心累。swagger 和 mock 这一套也推不动。真难

webpack 和 vue 全家桶能给带来什么？为什么非要推这一套，真的是被老代码折腾得够呛了，同名的有相同意义的函数定义了有十几个；一个页面引入十几个 js，其中定义了四五个同名的全局变量；这种依赖 js 加载顺序，谁后来谁牛逼的覆盖重写方式真的是噩梦；还有不同模块的 js 中有强依赖，还是相互依赖，debug 真不是一般的难；改动以前的业务既要抽丝剥茧，又要担心牵一发而动全身。

丰富的插件支持，一个命令便能开箱即用，更简单便捷的业务开发
项目化的前端工程，更有效的代码管理
代码检查，至少能避免基础的语法词法错误，已经各种声明定义错误
科学地打包，加强公用模块的提取，组件的高度复用，业务逻辑的剥离

经常有人吐槽屎山代码，webpack 能强制保证某些垃圾代码过不了编译。对于无需关系项目构建的业务开发人员来说，这一套东西实际上是提高纠错，降低开发门槛的。

[Marstin]

真的是进退两难，如果抱着老代码和工作方式不放，代码混轮，业务耦合，出点 bug 就改死人，个人能力也始终原地踏步，有什么意义？

[ajaxfunction]

说实话，我最反感的也是 前端组件化。

html + js 不好吗？ 每次发布非得重新打包 ，特别是遇到紧急事件，现场 debug，本来 vim 几分钟 搞定，

结果 光配置打包环境就办个小时过去了

[7654]

全家桶一点也不简洁 https://v2ex.com/static/img/doge.gif

[ironMan1995]

重构后，开发的可替代性更强。用全家桶开发效率快了，假如公司发现并不需要这么多开发了，裁人省成本美滋滋。让人家老员工在公司多待几年不好么

[coderluan]

这事完全是楼主的问题啊, 工作中职责没分清, 正确的做法是说服领导让他去安排. 你自己推不是自己给自己找事吗? 都是同级对方没必要听你的, 愿意不愿意尝试是别人的自由, 这不是难不难的问题, 而是想不想的问题, 人家不想, 你管不了, 你没这个权力, 这也不是你的职责.

[zdkkk]

你是领导吗？不是的话是领导授权你们改的吗？同事并没有配合你修改项目的义务。至于个人能力的提升，你也没权利要求同事和你一起提升。这种事没上层的推动，会搞得里外不是人，谁都看你不爽。

[Marstin]

@ajaxfunction 每种技术有其应用环境，你的生产环境可以随便更改，不发版的话，工程化项目化的前端自然麻烦，不如手写一个 js 文件替换简单
@7654 只是开发配置相对 html + js 麻烦，业务开发模块实际很简单吧，话说复杂的难道不是 webpack 吗= =Vue 不背这个锅

[Marstin]

@coderluan 已有授权，现在明确前后端分开开发，后端小组长负责，前端我负责，开发任务也是我分配的

[tabris17]

年纪大了就别搞前端了，头秃得厉害

[h82258652]

老项目能正常工作最好的做法就是别去动它。
要推新技术应该在新项目上做。

[Rwing]

java 为啥不换？

[hahaayaoyaoyao]

换人🐶

[coderluan]

@Marstin 那你管他们怎么想的呢, 正常安排工作就完了, 有问题你帮着解决就尽职尽责了.

[Marstin]

@h82258652 我的想法也是这样的，无奈领导的意思就是要兼容老项目。其实这倒还好，兼容老项目不难，想推新技术太难了
@Rwing java 也在换了，这个更麻烦一点
@hahaayaoyaoyao 这个更难，今年公司明确只出不进，走了俩了，都还不招人，工作压力越来越大，妈的

[NerverLibis]

能成功推行 MVC 都算成功

[Marstin]

@coderluan 坐我旁边一直在嘟囔，“这个怎么这么复杂啊”，“怎么这么难用”，“这什么命令啊”，然后还一直念叨我名字，我过去之后他又说没事。跟他们讲的时候就说，懂了懂了，套路懂了，完了之后，项目启动不起来，我一看，呵，啥命令都没执行，直接就打开个 html 访问了。光“npm install”和"npm run dev","yarn"这些我都讲了四五遍了，就感觉他们的搜索引擎就只用来搜索花边新闻的

[murmur]

vue 做单页面引用非常简单，非得上 webpack，那不抵制你抵制谁，mock 这东西，如果他后端认为开发速度足够快，不需要 mock 就不用 mock 啊

[murmur]

你说上 webpack 简单，每个 jsp 新加的时候你负责给配 entry ？这么多 entry 堆一起谁来维护

[ochatokori]

@ajaxfunction #2 打包环境还要重新配置的？
难道不是一次弄好之后都是一键部署的吗

[murmur]

vue 推下去是最简单的，让专业前端一折腾折腾的这么费劲，如果我推

1 、告知大家 vue 不影响以前的项目，你喜欢用 jquery 也可以，jquery 的组件也可以

2 、告知大家 vue 是替代你的 template，语法和 html 没有任何区别，学起来巨简单

3 、告知大家 vue 是填空题，把你需要的东西填到空里就可以，而且关键词巨简单，没有英语学习负担

4 、告知大家 vue 可以简化获取数据、赋值、权限相关的操作，这是双向绑定，爽到一批

完了，别的特性愿意学就学，不学不强求

[Marstin]

@murmur 我不知道你的“单页面引用”指的是什么，“单页应用” 还是 “CDN” ？ mock 的话，后端同事很支持使用……

[darktutu]

这个人肯定啥样都有，慢慢蚕食呢？一个一个模块搞，不愿搞的人维护老模块，新技术一个一个模块吃下来。水平有限不知道这样能不能完成

[murmur]

@Marstin 我有点不懂你们项目什么状态，是已经完成所有页面的 vue 改造，准备上 webpack，还是老页面 jsp+jq，新页面 jq+vue 两个技术并存，还是页面都是 jsp，让大家学习 vue 的用法？

我的建议是除非全推翻，不要大改，老页面如果没有需求变化，我碰都不会碰，新的页面用 vue 替代 template，让开发者尝到甜头，新项目再上 webpack

[tangtanghong]

如果像楼主说的只用撸业务层面的代码的话，真没什么难度，感觉再招一个水平好点的前端就可以全包，但是就会出现个问题，就像 4 楼说的，当老板意识到代码重构后开发效率增加，裁人就不可避免的

[coderluan]

@Marstin 带上耳机, 除非对方发消息或者来座位找你, 剩下的直接无视, 之后谁的锅谁背.

[ljpCN]

技术很多时候不是第一位的。如果你想要转型，你需要列出详细的 SWOT 去说服大家，同时充分引导大家发言听取大家的声音，商讨出最终的方案。你可能自己做了很多，甚至也考虑了迁移的成本，但是你的思考过程别人很可能没有完整地走一遍。

[wellsc]

后端推 kotlin vertx 就差不多了，java 切换到 node 确实费劲

[Marstin]

@murmur entry 可以按照规定规则的目录结构去读，不用每次都要重写。
老页面还是 jq，之前尝试过一段时间新页面 vue+jq 的，开发效果还不够满意，就想着继续推进，老页面不去动了，新页面全盘用 vue

[dapang1221]

组件化组件化，你去看看阿里云的控制台，重构了几遍，技术越来越炫酷，全都组件化了，骚操作一堆，但是现在呢，chrome 打开之后没 5 秒都渲染不完，还用个 p，每次打开阿里云控制台我就跟吃屎一样

[Marstin]

@wellsc 后端不转 node，跟其他服务交互比较多，产品功能细化，经常各种模块拆解或者组合来卖，目前就是要做微服务

[gouflv]

没啥意义，技术换血不是这么搞的

[liyang5945]

跟我去年的情况一毛一样，本来项目经理说要前后端分离，然后我自己研究搭建了 vue+element 的后台管理框架，然而老员工并不买账不想学，然后我忍不了就滚了

[sunmacarenas]

这种东西，明显就是吃力不讨好的事，建议让领导组织开个项目会议，定个基调推 VUE 全家桶，然后再开始搞

[heyjei]

从 jQuery 到 Vue 是一个过程，要慢慢让别人接受，不能一蹴而就。说实话，我刚接触 Vue 的时候，也很排斥，jQuery 用的好好的为什么要用 Vue ？！

别和我讲一堆的 Vue 哪里哪里厉害了，你要和我讲，Vue 可以帮我解决我的什么问题？你要站在人家的角度去说服人家才行。

推 Vue 可以按 @murmur 建议去推，双向的数据绑定，这个是巨大的诱惑，用惯了 jQuery 的人，已看到双向数据绑定会眼前一亮的，

Webpack 可以从第三方的 Vue UI 库开始推，iView，ElementUI，当他们发现原来前端开发可以搭积木时，就会有动力去学 Webpack 了，而且这个学也只是记住命令就行，不需要深入学配置和原理。（如果你的项目不需要这些第三方的 UI 库就另说了）

[atwoodSoInterest]

@murmur 太想当然了，不想学习岂是几句话推的动的，那是一个惯性状态。真要想学，vue 这个难度，看完教程就上手了。
而且我认为如果不是特别大的公司，技术栈还是要统一才好，要不然以后一个岗位需要各种技术，招聘难度又增加了许多。

[atwoodSoInterest]

这个技术推动很大程度上不是技术问题，是人和管理的问题，不想学的就真没有办法。但是出于你负责人的角度来说，应该 divide and conquer，先拉拢最不抵触的，然后再逐个击破，只要有人跟上了，其他的不愿意学的也只能骂着娘地学。

[happinessnch]

谨慎考虑：组员人多且都没有 Vue 技术栈。随便折腾：一共 3-4 个人。
谨慎考虑：线上稳定运营产品。 随便折腾：还没有上线。
谨慎考虑：长线运营平台型产品。 随便折腾：创新是错型产品。
谨慎考虑：产品性质为金融、电商、ToB 等以稳为主。 随便折腾：产品性质为娱乐等以迭代效率为主。

如果是线上稳定运营产品，不管调整后技术和未来迭代效率有多高，
上线后出问题，LZ 就背锅吧，事实上也确实是 LZ 的锅，最好的技术未必是最合适团队的。

[rockyou12]

不是专业前端 node 那套生态是要学一下，要知道好多写 java 的命令行都用不来，这行下限就是这么低……

[chanchan]

确实,vue 简单好用,和 vue 相关那堆东西让我难受

[littlewing]

跑得好好的，为啥要去重构，人力和时间成本怎么算？万一出问题了不是得不偿失？所以就破罐子破摔吧

[zengguibo]

如果系统跑得好好的，结构还行，维护还算方便，重构他做什么，太闲了？

[Shook]

公司用 require.js + vue + element-ui 写了好多项目，最初选用 require.js 的理由似乎是因为要去除 vue-router，于是现在是多页应用 + 自写路由的组合拳。
这样选型伴随的问题，还有打包残缺（插件太老用不了 babel，不能写 ES6 ）、依赖麻烦（.vue 文件拆成.html 和.js ，然后映射到 config.js ）、引入包麻烦（改 element-ui 的源码还得打包一遍）。

虽然我是挺想用脚手架重写一套的，不过看同事们规范你一套我一套，而且项目一来基本都很赶，有事就是“赶项目”，这样做似乎吃力不讨好，为了不浪费自己的下班时间，于是作罢。
不过前段时间推了自己用 koa 搭的 mock-server，把 controller 、util 什么的全部做成自动引入，感觉挺还不错的。

[CODEWEA]

楼主是犯了做技术的通病,对于项目的推进只看到了技术

[peper]

楼主喜欢用新技术, 何不跳槽到用新技术的公司呢? 改变不了同事还改变不了自己? 都是同一个公司拿工资混饭吃的人, 何必呢?

[dolphintwo]

又不是不能用

[dolphintwo]

软件卖的从来都不是技术栈

[bk201]

换新技术带来的是什么？

[leftstick]

楼主想法是 ok 的，不过你的环境不允许。你就是死水里的那个鲶鱼，有人以为一条鲶鱼能把死水搅活，那是幼稚。

每个人的目的，动机，爱好，体力，智力，都不尽相同。

运气不好，你就碰上了一帮对技术没热情的划水派队友，相信我，天下人多了，哪里这类人都是多数。不然 gayhub，v2ex 也不会成为一部分人的主要『社交』工具了，还不是因为周围人都没有共同语言么？

这种情况下，要不你有本事能推动招聘，招更多和你心思相近的人来，反向给划水者驱动力；要不你能给大领导（有决策权的）提供你这套方案在业务上能提高多少竞争力，诱惑大领导给下面施压（这种效果其实不算好，因为划水派依旧可能不愿配合，并把自己的所有失误全都归罪于你这套新方案上）；要么你走人，找一家思路相近的同事比较多的企业去；

最后，我建议第三条，因为找到一帮志同道合的人一起工作，才是最开心的。哪里干活不是干

[TtTtTtT]

我觉得是好事，任何对于投入产出比有利，降低社会必要劳动时间的行为，都是合理的。
从另一方面来说，应对诸如 @ajaxfunction 这种实际上应该被淘汰的 API 工人，应该使用温和的疏远方式。
应对保守型的同事是一个必要的功课，而这个正是跨向领导型人才的必要课程。
祝好运！

[dongguangming]

记住时代抛弃人时连招呼都不打

[maemual]

我觉得推进新技术，对于其他员工，没有 show 出足够吸引人的好处。他们没有尝到甜头，所以比较抗拒。

[jsjgjbzhang]

项目的价值不是技术方向决定的

[gadsavesme]

jsp+jquery，所以之前都是后端一把梭吗？如果是我我在后端的角度我也不高兴去从头学前端那一套东西，有这时间我自己研究研究后端感兴趣的东西不好吗。当然如果是前端只会 jquery，那真是有点难以想象。

[maxxfire]

新技术用在新的项目上

[smilzman]

不要主动去推！不要主动去推！推好了没好处，平白得罪人，推不好你会被杀了祭天，用来安抚其他人。

[Ritr]

新项目再上新技术吧，另外 vue 全家桶其实一点也不轻松，有一说一既然都上全家桶了为何不上 angular，完善的工具链，统一的代码风格多好

[Marstin]

@gadsavesme 分出来几个做前端了，这几个人之前也是主要写页面的
@jsjgjbzhang 项目的可维护性和扩展性是由技术决定的，其他条件都相等的前提下，技术方向也是技术人员的 KPI

[karlkor]

> 之前我就已经在项目中用 CDN 方式引入 Vue 来使用，理论上来说已经能够适应 vue 的开发节奏了

直接在 MVC 架构下使用 Vue 也是没问题的，尤雨溪推荐过这样使用 Vue，不一定非要用上 Webpack 做成 SPA 。

[yaphets666]

你可以跳槽 但是他们这些人会被淘汰的 他们跳不了槽了

[coderxy]

如果你能一己之力搞定新技术栈，就去搞。 如果会影响其它同事，只要他们不愿意他们就可以不同意。 这是个人自由，没有毛病。

[wxsm]

老项目没必要，也不应该转型。稳定为主。这件事你做得不好。

[alienx717]

按理说应该高兴才多了，线上虽然老但是业务方能继续使用，技术团队做一个新版出来，还有年轻同事带你飞这些老头坏得很

[Rwing]

@Marstin java 换啥，我推荐 C# 😏

[leafShimple]

你给的钱 我很难配合你一起重构优化啊.年轻人

[xiangyuecn]

讲真，代码什么的是次要的，怎么舒服怎么来，能赚钱的项目堆屎山也能赚钱，不赚钱的写出花来也没奖金

[lp7631010]

讲这么多你是不是领导啊 现在问题是到底是谁要推 如果是领导的话 那么问题就好办了 如果不是 你费这劲干嘛

[raffaellolin]

能赚钱吗？能就干

[yorkw]

能稳定运行且能给公司持续盈利的项目，即便是屎山也最好不要轻易重构，新技术和漂亮的代码，除非你能保证重构 /写之后 100%不出问题，否则的话在稳定面前就是一坨新屎，况且某些陈年屎山一般都经历过反复的线上问题洗礼和调试打磨，业务逻辑都融入代码里面了，之前有见过按照需求文档把尸山重构崩了，给公司的业务造成损失，自己走人的

[zhw2590582]

我觉得真没必要这样重构，能用能赚钱就行

[Marstin]

@karlkor CDN 方式的结果是 vue 变成了另一个 jQuery，以此方式写出的代码还是相同的路数

[Marstin]

@zhw2590582 运行肯定是能运行的，就是没法维护，新的功能也是在相同项目中开发，更搞不动了

[choudidi]

不明觉厉，好牛逼的样子！

[leafre]

前端现在乱得很，还好我只折腾后端

[wangyzj]

想想投入产出比
这么高的投入会获得什么
公司效益不提升可能还会带来短期下降
so.......

[Varobjs]

npm install 环境报错能卡住一大波人

[prenwang]

这种改革必须自上而下, 劝是不可能的. 该做恶人就做恶人. 上纲上线, 不服就滚

[sunziren]

你就站在那里说：“现在统统听我的！谁同意？谁反对？”（注意穿黑色西装）

[NeezerGu]

我觉得你得先说清楚，几线城市，朝几晚几，什么样的公司。

如果一个三线城市，朝九晚五，属于饿不死但也赚不了大钱的公司，你给我聊这些我铁定当你奋斗逼。
但如果一线城市，996，老板一门心思想好好搞了上市的，那就说明你们老大灌得鸡汤不够多

[jon]

老项目不是有太大问题都不大改

[DJQTDJ]

老项目你都敢改，牛皮。
老项目给我我都不想碰，一旦碰坏了，这 tm 就是你的错了

[Jinnn]

改变不了别人就改变自己, 找个肯用新技术的公司就没有烦恼,
毕竟总有人不想学新的东西, 你叫不醒装睡的人, 洗洗睡吧

[redbuck]

我司旧项目我是不改的,要加新东西直接 iframe 上.我这边用啥都好,反正给他们编译到位,啥意见都没有.

[ericwood067]

老代码重构的确是风险挺大的，主要是你们老板愿不愿意推这个（嘴上说的不算，可能老板也是随便说说的，不知道里面的问题及风险，要协助你推进并承担一定风险）。如果老板没有真心觉得这个是必要的，你重构蹦了，或者因为引入的新技术导致其他不熟悉的同事负责的业务蹦了；这个时候你可能就是首当其冲背锅侠了。

[jiom]

我之前也试过，jsp 页面上有各种代码，后面我只能新功能自己改。旧的只能保持原样不报错已经谢谢前辈了~

[fhsan]

等过两年 vue 也成历史包袱了，相信 js - require - angular - vue

[glfpes]

提出方案会上讨论，让老板决定。

[imn1]

改革的发起虽然多数都是自下而上，但定调还是自上而下的，你要了解这个规律 /定律

[fgk]

除了领导拍板，其他人决定的一律无效啊

[nnnToTnnn]

新技术能带来什么？

1. 项目模块过多（超级多的时候）页面过多在 build 的时候会无比的慢。 特别是 Babel 转 es5 的时候。
2. 额外的学习成本。
3. 不可把控的技术架构。万一除了什么问题，你们公司有 jquery 厉害的人来进行解决以及寻找 BUG，如果换了 webpack + vue，如何保证和快速定位？ 别站在你的角度上，站在不会的人角度上考虑。
4. 如果 webpack 出现和构建问题，以及打包出现了问题，如何解决问题？
5. 如果 vue 组件出现了性能问题，楼主能提供保证吗？

除非是新项目，老的项目让我推新技术，我也是万万不敢的，因为太多东西不敢保证了。

[nnnToTnnn]

新项目推 React， 一堆同事说不愿意用，或者为什么不用 Vue 。

用 React 留在团队前端，如果不愿意，可以转到其他岗位，或者其他团队。 我是这样推 React 的。 (*/ω＼*)

[fengerzh]

问题还在于你是不是领导。如果你是领导，强令必须这么干，不干就滚，你看，事情很容易就解决了。如果你不是领导，那么其他人为什么要听你的？你去说服领导？快算了吧，领导会考虑其他同事的感受，很大可能结果是：小王，你的想法很好，但是 blah blah blah 。所以你优先的当务之急不是考虑推广什么新技术，而是考虑如何尽快让自己当上领导。

[karnaugh]

同感，至于问为什么必须要 vue 那一套的，我现在的感触就是 原生 js&jquery 太 tm 自由了，怎么写的都有，最终几个人一起迭代一个项目后就会变的乱七八糟，说还说不得

[toesbieya]

嗦实话，我也是很抵触 webpack 那一套，主要是 node_modules 太恶心人了，要是什么时候前端能不考虑兼容性直接用 esm 写法那多舒服

[levn]

想当领导也得有那个领导能力

[suzic]

太难了，新项目再分离吧，旧的项目用 cdn 引入就行了

[zxCoder]

那几个员工年薪多少，还不如招几个我这种实习生 23333

[learningman]

> 定义了四五个同名的全局变量
之前看学习通代码就发现这个情况了哈哈，有一个 xhr 获取的信息，其实在页面里有三四个 dom 有这个值，一看就知道是服务端渲染+前后端分离，天才开发

[zr8657]

你是决策人吗，不是的话不要管，听着干就完了，何必去做这些吃力不讨好的事

[gzchen]

把老家伙开了不就行了吗？

[learningman]

@karlkor 但是这样体积多 50k 还是 gzip 后