怎么说服公司老人用新技术？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2120 天前的主题，其中的信息可能已经有所发展或是发生改变。

公司有一个技术主管，大概 10 多年前写代码的，现在不写了。公司最近有一个项目是后台管理系统，100 多个表的 CRUD，我想用 react + react router 做前端，但他不愿意，想用 JSP，而且还是超级复杂的 JSTL 库。

<kendo:grid name="grid" groupable="true" sortable="true" style="height:550px;"> <kendo:grid-pageable refresh="true" pageSizes="true" buttonCount="5"> </kendo:grid-pageable> kendo:grid-columns <kendo:grid-column title="Contact Name" field="contactName" width="240" template="

#: contactName #

"> </kendo:grid-column> <kendo:grid-column title="Contact Title" field="contactTitle" /> <kendo:grid-column title="Company Name" field="companyName" /> <kendo:grid-column title="Country" field="country" width="150" /> </kendo:grid-columns> <kendo:dataSource pageSize="10"> kendo:dataSource-schema kendo:dataSource-schema-model kendo:dataSource-schema-model-fields <kendo:dataSource-schema-model-field name="contactName" type="string" /> <kendo:dataSource-schema-model-field name="contactTitle" type="string" /> <kendo:dataSource-schema-model-field name="companyName" type="string" /> <kendo:dataSource-schema-model-field name="country" type="string" /> </kendo:dataSource-schema-model-fields> </kendo:dataSource-schema-model> </kendo:dataSource-schema> kendo:dataSource-transport <kendo:dataSource-transport-read url="${transportReadUrl}"/> </kendo:dataSource-transport> </kendo:dataSource> </kendo:grid>

除了换工作，还有别的办法抢救一下么？

65 条回复 • 2020-11-19 14:00:07 +08:00

murmur

2019-02-11 17:16:23 +08:00

你推荐 vue 可能还有希望，react 的学习曲线有点陡，他用 jsp 能完成，说明这开发主要部分是在渲染部分，还是传统的模板套数据的思路，这个时候你用 jsx+各种 css module 写不是自讨没趣么

jrient

2019-02-11 17:18:26 +08:00

所有的革新之前都要做好自己一个人担下所有工作的准备。
如果有热情，压缩现有的工作，腾出时间来自己完成这个目标。一旦完成了还得不到支持的话，那我就建议你换工作了。

jrient

2019-02-11 17:19:46 +08:00

@murmur 前端方面我不太懂，确实如果你推荐的是一个学习维护成本很高的技能，不过也是常理。

murmur

2019-02-11 17:20:53 +08:00

@jrient 我记得一直有个人在 v2 打广告可以快速配置出 ajax 接口的一个 star 挺多的一个东西，突然想不起来叫啥了

hellowes

2019-02-11 17:22:07 +08:00

许多前端只是为了自己着想，怎么爽就怎么来，也不考虑自己的项目有无必要重构，重构后能不能带来收益

letitbesqzr

2019-02-11 17:30:50 +08:00

看起来是使用了 kendo ui 配套的 jsp 标签库，你确定你一个人维护的框架能有这套成熟的商业框架好用？

murmur

2019-02-11 17:33:03 +08:00

@letitbesqzr kendo ui 做了 vue react jquery 的支持。。

jssyxzy

2019-02-11 17:34:59 +08:00

没有，

letitbesqzr

2019-02-11 17:35:02 +08:00

@murmur #7 那楼主的吐槽不就毫无意义了？用 jsp 和用 react + react router 没什么关系啊？

mgso

2019-02-11 17:35:16 +08:00

一样. 但是我看了我们的整个项目. 还是用 jsp 吧
首先东西太多太杂,业务乱.
其次没人愿意跟我重构
再者公司不愿意花着时间

murmur

2019-02-11 17:39:34 +08:00

@letitbesqzr jsp 似乎这套封装直接绑定了数据集，用了 react 和 vue 就得写配套接口了吧
我没仔细看

ifxo

2019-02-11 17:40:24 +08:00

你干你的管他呢

Foxkeh

2019-02-11 18:04:22 +08:00 via Android

一个月前不是有人发过类似的贴么

beginor

2019-02-11 18:12:41 +08:00 via Android

这个要看用前端渲染带来的收益是否大于成本

imkerberos

2019-02-11 18:15:33 +08:00

为啥要重写? 不满足需求? 能带来额外收益? 投入产出比是什么?

boris1993

2019-02-11 18:17:00 +08:00 via Android

@murmur #4 JSONAPI 还是 APIJSON 来着

allanzhuo

2019-02-11 18:19:12 +08:00

领导又领导的想法，你用的技术他不会，你会走他基本不会走，所以不愿意给自己埋坑。还是技术上说服他吧，不然都不愿意干，你自己干也累

iAcn

2019-02-11 18:25:15 +08:00 via Android

推荐新技术，用上了，挺好，不是你实际做的，你的好处不大。没弄好，你就是背锅侠。

gongqi044

2019-02-11 18:31:53 +08:00 via Android

说服自己不用即可

x86

2019-02-11 18:44:55 +08:00

稳定就行了，别整这些花里胡哨的

sumu

2019-02-11 19:25:12 +08:00 via iPhone

前端技术我是服气的，变化太快了，越来越高级，还是后台好，十年才有一次技术栈大升级

luoway

2019-02-11 19:36:21 +08:00

用 React 做个 Demo 比较一下代码量，真的差距明显也不接受，那试试 Vue （当然最好一次比较完），还不接受那就换工作。

zhuangzhuang1988

2019-02-11 19:40:38 +08:00

稳定就行了
咋不说让 vscode 团队用 react/vue/angular 呢

mcguffen

2019-02-11 19:41:06 +08:00

这是银行外包工作？还有用 jsp 的

CFO

2019-02-11 19:43:23 +08:00 via Android

我们组用个新技术都得我弄得差不多了他们进来填逻辑升级或者引入新工具什么的更是得我自己一个人弄他们别来添乱就谢天谢地了给个模板照着写都写不好
准备溜了还是得和牛逼的人在一起工作

WordTian

2019-02-11 20:02:01 +08:00 via Android

说服别人很难的，除非你是领导👻

zwh2698

2019-02-11 20:10:23 +08:00 via Android

换主管吧，没啥好说的。一个好的主管应该在风险可控的情况，给手下最大的自由度。因为只有让手下尝试，才会成长，才会更好为自己攻城略地。如果一味这个是风险，那个是风险，那就真的很没格调。我从来只是分配任务，交流想法，不约速我们兄弟和姐妹的自由，遇到困难你来找我就行，我给你想办法解决，如果很顺利，请不要打扰我，我也很忙。哈哈

geekboy

2019-02-11 20:17:50 +08:00 via iPhone

@mcguffen 老项目 JSP 正常

yiyi11

2019-02-11 21:52:45 +08:00

如果你是技术主管，或者你能扛下技术主管的责任，那就坚持你的方案。
如果没有这个能力又要坚持，建议跳槽，或者继续在该公司积累业务经验，直到你觉得能驾吁整个项目的时候再提出你的方案。

yiyi11

2019-02-11 22:01:56 +08:00

越是正规的产品，代码达到一定规模之后，写代码是简单的，维护代码才难，假如你写出来了就离职，你预计下接手维护项目的人，需要花费多少成本来上手（这里就要根据实际情况来综合考虑，比如同事跟你的技术栈是否一致，水平是否一致，比如用某个技术招人好不好招等等）。

loading

2019-02-11 22:19:12 +08:00 via Android

技术主管:你精通了 javascript?没有就给我继续干，我精通了 jsp。

kaneg

2019-02-11 22:21:32 +08:00

可以试试前后端分离，后端用 rest API，前端用容易上手的 vue，这样既不至于搞得一团乱麻，也不至于把其他开发人员吓走(这是说 react，说实话，我看到 react 用 xml 方式写 js，感觉自己已经跟不上时代了)

cnbattle

2019-02-11 22:44:30 +08:00 via Android

看具体需求，使用场景，公司技术栈

个人想法，中小型管理后台系统这样，前后端分离会增加开发和维护成本

即使分离也是优选 vue …

likuku

2019-02-11 22:48:42 +08:00

一天内你完成项目，完全满足需求，主动交给这位老人，并告知功劳都算他的，这样对方还会有不愿意的？

qianmeng

2019-02-11 22:58:28 +08:00 via Android

如无必要，请勿带头趟雷

cleveryun

2019-02-11 23:18:28 +08:00

JSP 基本就是多页应用了，访问体验和单页应用（后台系统+react 默认你是想弄 SPA ）差别还是挺大的。vue 跟 jsp 的差别相对小一些（模版），react 的相对大一些，前者肯定会好推一些，不过另外一点就是 node package，对应的这些 npm run blabla, yarn blabla 这些他们也不一定顺手。或者你可以从 UI 库入口来尝试推，element-ui、ant-design 这些比 bootstrap 要好看些。

不过就如 @qianmeng 说的一样，带头趟雷需要你有一定的觉悟。

785999159

2019-02-12 02:34:16 +08:00

jsp 其实挺好的，尤其是考虑到代码的维护性

ericgui

2019-02-12 04:09:51 +08:00

跳槽吧

herebury

2019-02-12 04:13:31 +08:00

别的不好说，但是 kendo 一定是个大辣鸡。我觉得所有脑子能思考的前端都最终会受不了 kendo，因为这玩意没法做任何不把自己恶心死的 customization

m2276699

2019-02-12 07:48:29 +08:00

新技术需要匹配现有团队，如果你离职了，项目怎么办？

duan602728596

2019-02-12 07:49:54 +08:00 via iPhone

都 9102 年了，react 还算新技术？前后端好不容易解耦，各干各的，互不影响。用回 jsp，这还开历*史*的*倒*车了。
用 jsp，不仅仅是放弃了前后端分离带来的好处：
1. 前后端分离开发，相互之间的影响很小
2. 使用 webpack，模块化打包前端代码
3. 在开发时，可以做到代码热替换，可以使用 babel，可以使用 css 预处理器等等
4. 打包时，打包代码的同时还可以做到按需加载代码，静态文件地址自动写入 html 标签，压缩 css、js 代码、压缩图片
5. NPM 管理依赖

用回 jsp，除了享受不到前后端分离的优点外，还会
1. 放弃 ES6，只能写 ES5 以下版本的代码，且要自己处理一些兼容问题
2. 不能够使用 A、R、V 三大框架。使用 jquery，除了要写业务代码、还要写操作 DOM 的代码
3. css、js 文件混乱的管理：到时候势必会 head 标签内一堆乱七八糟的样式表、body 标签内一堆乱七八糟的 js 文件。

CasualYours

2019-02-12 08:10:59 +08:00

其实我觉得从 jsp 过渡到 jsx 挺自然的，这种后台管理系统是非常适用 SPA 和目前的前端框架。

说服公司的同事使用新技术，一定要对这个新技术有足够的了解以及风险评估。最起码自己有能力解决重构过程中的各种问题，不然就是又开了一个新的坑。

Mac

2019-02-12 08:11:53 +08:00 via Android

你先说说把前后端分离后能少养几个人吧？

rocksolid

2019-02-12 08:26:13 +08:00

1 证明实现项目没有技术困难
2 证明换技术有好处(加快进度,或者你们团队更熟悉新技术)
3 其他成员都愿意

ahaodady

2019-02-12 08:43:17 +08:00

1 你要保证你重构的东西你要负责到底，谁能保证你会不会拍拍屁股走人；
2 正如你说，主管以前写代码现在不写（正因为他不写代码了），如果换做是我而且我也不写代码了，除非到了碰到瓶颈，不然我也不想动这块，毕竟新技术给他带来的不确定性，招个人来维护你懂的系统容易，哪怕招不到人，到不了我自己上，因为最起码我自己会也看得懂。
3 其实以上两点从公司层面考虑已经够了（一个后台的项目管理系统而已，几个人用？有什么瓶颈？是吧）

greatghoul

2019-02-12 08:54:23 +08:00

你的后台管理真的复杂到需要 react 吗，不是说仅仅是简单的 crud 而已嘛，不要给简单的项目加入过多的依赖。

qiukong

2019-02-12 09:05:56 +08:00

如果楼主愿意且有能力一个人把所有活都揽下来别人坐享其成，那就大胆地提出来。
否则别去捅这篓子。

jeffersonpig

2019-02-12 09:21:12 +08:00

25 楼就是一意孤行强推新技术结果没能力带不动团队自己又扛不住工作量最后跑路留下一堆烂摊子让别人收拾的典型

huanchena

2019-02-12 09:22:04 +08:00

@jeffersonpig +1

jeffersonpig

2019-02-12 09:23:14 +08:00

自己内心都还想要牛逼的人带的，就不要逞能装逼搞事情了，最次不要搞砸了以后怪别人。

lixiangzaizheli

2019-02-12 09:31:11 +08:00

@hellowes 许多人只是为了自己着想，怎么爽就怎么来，也不考虑自己的项目有无必要重构，重构后能不能带来收益
前端 -> 人

simonguo

2019-02-12 09:31:16 +08:00 via iPhone

技术选型是要讲究客观条件的
你把选型的优势劣势都列出来，时间成本等都有用数字化展示给高层看，最终决定由他们来衡量。

如果你的方案是最优解，我相信会被采纳。如果公司最终采纳的方案不客观，你不能接受，甚至影响你的技术成长，可以离职了。

suzic

2019-02-12 09:49:13 +08:00

用 Vue 好啦，直接 CDN 引入，像 jQuery 一样，连 webpack 都不需要
以后公司有靠谱前端了再用其它技术栈，或者你自己直接包揽前后端。

lihongming

2019-02-12 10:03:13 +08:00 via iPhone

只见过技术总监盲目追新把公司玩死的，没见过技术总监固步自封把公司拖死的。

对绝大多数公司来说，技术部只是个职能部门，不是核心竞争力。老技术能实现的，就不要去改。

你改完你爽了，头上也有了用新技术做过大项目的光环。但你能保证没 bug 吗？这些 bug 需要多久才能修复到跟原有老系统一样的稳定性？影响的业务怎么算？

win7pro

2019-02-12 10:03:40 +08:00 via Android

建议：
1.你要了解现有技术和业务瓶颈，能说出现在的技术方案问题在哪里，优先指出目前方案对业务的弊端，新技术能给业务带来什么好处。
2.实在不能从业务层面指出的话就从技术角度（安全，运行效率，性能，可维护性等）来说，但此时你的筹码已经大打折扣了。
3.如果推新技术仅仅因为新而去推，这个不能算是一个理由，因为对于已经稳定的业务和系统，完全没理由因为有新的技术出现就冒着各种风险去替换原来已经稳定的系统。
4.退一步，先自己用新技术业余搞，新系统搞出来个大概后，再找老大来看，或者和老大商讨一边维护老的一边开发新的，得到老大认可后找合适机会做新旧切换。
5.诱导你老大开条件，比如老系统服务可靠性 98.0，如果新系统可以达到 99.9 就采纳上线等条件。
6.和老大搞好关系，陪吃陪喝，让他给你一个机会…