公司代码理念不一样咋办

[livingwolf]

前端，因以前公司业务不好，清闲了一年多，觉得这样下去不行，跳槽到现在公司，觉得现在公司的前端代码实在是太乱了，于是提出了重构版本，郁闷了。本人菜鸟，还是想提高自己水平的。
1、觉得以前文件结构目录不规范，所有页面都放在 components，提出页面放在 views 或 pages，组件放在 components，就这，说就好看点，所有提出来的组件应该要封装插件。
2、以前代码写的太乱，var、let、const 乱用，很多都没规范，提出用 eslint 进行代码质量检测，被拒了，说照 eslint 规范写太累了
3、公共方法杂乱，光是时间戳处理页面就好几个，每个人都写各自一个，但是有人说代码能跑就行，里面不用关心
4、同事固步自封，都 2019 了，es6 都还不熟悉，跟他们说 es6 语法，有个人竟然说会用以前写法，这样也不用编译，特么我无语了
5、有个后端同事觉得自己全栈，写出代码 if for 一堆，一直用 var，我用 array 的 some、every 竟然被说成最优写法，唉。
6、所有页面耦合性太高，比如主页面，侧边栏、头部、尾部等操作全都写在一个页面里，提出提取出来，被说只是好看
是我太过轻狂了吗？我觉得如果是一个项目你写完可以不管，但是是一个一直维护的产品的话，代码质量是非常重要的。
唉，辞职是不可能了，怎么端正自己心态了？

感谢大家批评，too young too simple。
关于这个产品，是个后台管理系统，比我以前写过的都简单，以前基本上还是一个人写，这个项目有四五个人，以为重构也花不了多久，这是我太想当然了。
我提出的思路是以前老业务的不变，建立 2.0 版本，以后新的业务在 2.0 的基础上，再慢慢迁移以前老业务
但是大家说的也对，同级人不愿意这样费力，没办法
跳槽才是上上策，但是个人原因，还不能跳槽
担心这种氛围下，自己学习动力、代码能力下降，但其实除了工作还有很多提高自己能力的事情
我自己默默重构，不再叽叽歪歪了，也不会再提这些事了，领导怎么说怎么做吧

[xiaohuamao]

某种意义上程序员就两种人：全天下老子第一 全天下老子最菜，你属哪种

[ThomasZ]

做好自己的，在你没有相关职务的时候这些想法不会被认可还可能造成矛盾，只有你有一定的话语权的时候才好使，至于自我充电那更是个人事情了。所以做好自己的工作，充实自己，在合适的时候跳槽还是靠谱

[serge001]

没办法, 这种问题已经讨论过很多次了, 除非用行政的力量干预, 否则同级没人会听你的....毕竟很多人不仅仅对代码, 对很多东西都没追求的

[livingwolf]

@xiaohuamao 那我不属于程序员，哈哈哈，我觉得比我厉害的人很多，比我菜的人不少

[smilingsun]

我以前也有这样的想法，不过我觉得

比写代码更难的是读代码
你以为你写的代码容易懂别人不一定觉得

[livingwolf]

@smilingsun 我以为我说的都是基本的，只是代码规范问题，都不涉及到读懂读不懂的事

[whileFalse]

建议在不影响用户和其他同事的情况下重构。

先把运行正常、不需要维护的页面重构掉。重构的时候用代码对比工具仔细查看想提取成模块的重复代码是否有细微的不一致。别大大咧咧重构完了功能被改掉了。重构完成后多测试。确认没问题了可以邀邀功，“之前有 5k 行代码，经过整理减少到 2k 行，目录结构拆解清晰，逻辑更加易读”

如果要推 es6，尽量做到让同事无感。别人家早上一来一更新代码卧槽编译不通过了。建议首先在你自己的组件中使用 es6，把编译后的代码和编译之前的都 commit 到版本控制里，保证同事们即使不安装 babel 也能正常使用。先让大家看到 es6 的爽点，再来谈论要不要上。

好好积攒经验值然后找到逼格更高的公司是上策；升为主管然后整理技术团队是中策，逼着别人用你刚学的雕虫小技是下下策。很多人就是来混口饭吃，复制粘贴多爽，“你算什么玩意”。

[13662439966]

某种意义上来讲，这还是回归到六字箴言当中

[BingoXuan]

六字真言送给你，要么忍要么滚

[qiutianaimeili]

还是太年轻。。。喜欢纠结这种小问题。

[livingwolf]

@whileFalse 现在项目用的是 vue 全家桶，不存在说 es6 编译不过，他们也用了点 es6，不过不规范。vue 也是，有些真的只是代码规范问题。
推广 es6，我现在是不指望了，从我一进去就问我 var、let 区别，到现在还问这个，就算我说不明白，真有心，自己去看书也行。
看大家说的，觉得我还是做只咸鱼吧，自己研究自己的，公司叫我做啥就做啥吧
因为已婚未孕，跳槽有点麻烦，现在

[ooppstef]

只是角度不同而已.

从公司的角度,你重构一需要资源(工时等),二来本身稳定的程序可能造成 bug.这种只有坏处没有好处的事情,公司怎么想?

更好的做法是,通过优化自己的模块+利用空闲时间一步步优化其他模块.在团队中证明你自己,拿到权限就好了

[nfroot]

重构是大工程啊。。。。

[solaro]

公司花钱聘请你来干活得，不是来提意见得，你还年轻

[TomVista]

代码写的乱,这点我同意你的想法,但是让同事用 es6 是你不对.

固步自封 if for array some var let???

不要想着推 es6 了,着手规范代码结构把.

[otakustay]

现在大概不分 page 和 view，全是 component 是主流

[tabris17]

你知道什么叫 DDD 么？ deadline driven development

[jmc891205]

这问题大公司小公司都有
你就算去了 Google/Microsoft，如果要维护一个有好几年甚至十几年历史的产品，你会更抓狂。

[zr8657]

没事别给自己填堵，有这功夫不如去造轮子。你想想为什么同一个文件里会有“ getUser、getUser1、getUserLsq ”？

[liaoguiming]

如有机会(新需求，新项目)，不影响他人的情况下，自己按照自己的方式写就行了。

[coderluan]

如果你们公司很忙，那样这样情有可原，起码不是小领导和一般同事的锅，或者说轮到你了你也这样。

否则的话，离职是最好选择，暂时不能跳槽的话，也别管他们代码质量，千万别改他们代码，直接当成第三方库用就行了，谁的问题谁处理，你自己代码写好点就行了。

[bjfane]

就像 XX，不能改变就享受吧。

[mars0prince]

早点离职吧，这种情况往往是公司技术风气不行，我在过这种公司，想用个 vue 都不能，后来公司里技术好的全走了。找了家技术氛围好的，leader 会自己推动技术重构和新技术实验，像这种老项目会专门找人进行分步重构，产品方也很支持。

[livingwolf]

@jmc891205 其实我之前维护过一个很烂的代码，甚至比现在更烂，但是因为对我来说，同事都蛮有想法，蛮厉害的，因此我们也是经常调侃代码差，但不需要长期维护，我们也不会重构，经常往烂代码里扔垃圾。最主要其实我郁闷的是团队里的人员，感觉是个没生命力的项目。

[whypool]

这就是屎一样的代码了，见多了就不奇怪

能跑就没毛病

[WilliamYang]

如果周围的同事都是技术上没什么追求, 我自己觉得很难受, 我庆幸自己遇到了和我理念一样的前端, 合作的比较开心

[shyrock]

@livingwolf 从我一进去就问我 var、let 区别，到现在还问这个，就算我说不明白，真有心，自己去看书也行。
这句话的意思是你不明白？？？

[livingwolf]

@shyrock 我的意思是我已经说过很多遍了为什么推荐用 let、const，但是一直有人问我，他们真的有心想弄清楚，就算我表达不清楚，他们也会去看书的，都写的清清楚楚有例子。

[lingll]

成本与收益的问题

[passerbytiny]

关键看工作强度，如果你能有一半的工作时间可以搞自己的，那就留下，否则，跳槽要趁早。如果是留下，那么要找机会成为新项目的负责人，或者努力成为老大。

[zzzzzzZ]

别这么极端，没什么大事情的，你这样想法的人太多了
既然没本事命令别人用你指定的技术栈，“不用 /不会用就滚”。何必私底下来抱怨别人的没本事呢
当屁股没有坐到能够决定公司 /项目技术栈的时候，就不要想这些有的没的，老老实实沉淀自己
就算觉得技术栈有必要提升，也是直接跟屁股坐在那个决定者上的人“沟通”“提议”“交流”
跟和你一个级别、资历还比你老、又其实和你一样屁都决定不了的人说有毛用啊

[randyo]

我们公司要求用 jQuery，前端代码后端要能改

[dcatfly]

eslint 都被拒，我个人觉得无法接受。。

[66261123]

楼主还是太年轻，代码无分好坏，只要能赚钱的代码就是好代码

[method]

其实没那么重要。
别做这种费力不讨好的事。想提升技术能力，可以多参与开源项目。

[luren123]

不要总想着自己顶天立地，尊重当下，毕竟系统运行的 ok 才是关键，做好以后新开发的内容，逐步迭代
哪有那么多完美的事情