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

• 主 資深大佬 : 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 后