真实的职场经历往往能引起大家的共鸣，被 V 友 @totoro52 的一句 "永远不要跟老板提系统的改动和重构，他们永远都不会答应的，他们只会觉得 这只会浪费时间和人力" 触动。
本人也是刚入职一家公司不久，7 年后端了，技术马马虎虎，胜在有一些中厂经验。之前搞过创业，也带过团队，后来被人坑了，又回归到正常的工作。 带过团队经历过，确认自己是不适合搞管理的，不太擅长沟通（喜欢有挑战的事情自己做，不放心，把活分配出去总觉得不好意思，没法对团队施压，甩黑脸等等，简单来讲就是心软或者软弱懦弱）只想做好自己的事情。
新的团队业务倒也没有很复杂，但代码不怎么规范有点乱，初来乍到，花了很多心思在优化重构上，结果被直接 leader 各种拐弯抹角，说了很多次，说你觉得是优化重构，其实不过是审美问题，每个人都有自己的想法和喜好，有些人就喜欢一堆 if else 一个方法几百行也没问题。 就总认为我的工作，仅仅是让代码变的好看了，于团队全然没有帮助，甚至会让有些人不习惯影响开发效率。可能他都觉得我是在做无用功吧，连续几周对我的评价都是，不要钻技术细节，要从全局去看。。。。。。哎。
 |
F281M6Dh8DXpD1g2Jun 18, 2021
1
领别人的工资按别人的要求做事呗
|
 |
yungo8Jun 18, 2021 via Android
2
我和你第二段是相似的，第三段，如果能提升效率还是可以，没有啥大用处的话没必要花精力去搞的，写好自己的代码就好
|
 |
koakeJun 18, 2021
3
重构这种事件，如果是小团队的话，还是比较适合在保证进度的前提下进行。如果不是大面积的话，其实大部分重构都是在这段代码实在是看不懂了的情况下才进行的 😂
|
 |
BBCCBBJun 18, 2021
4
对的, 保证你产出的前提下再去做额外的事情.
|
 |
5
大部分公司都是业务导向的，纯技术导向的公司真的不多。
那篇文章我也看了，私以为雷军说的那句话还是有些道理的，新员工多看多听多想少提意见，很多事情不是大家没想到，而是推不动。重构可以，收益怎么计算？能体现在你老板的 PPT 里吗？不能的话那对部门也未必是好事。 平时写代码用高标准要求自己就好了，前人写的代码，在不知道他是什么场景下完成的情况下，少评价，除非有 bug |
 |
kop1989Jun 18, 2021
6
这里面你犯了一个基本错误。即：程序的重构应该是你们技术团队内部风险对冲的一种举措，为何会捅到上面去？作为一个商业视角的决策者，怎么可能会同意大成本的，仅有技术意义的重构？
当一个重构带来的是额外的成本，而不是收益的时候，重构真的是重构么？ |
 |
Y29tL2gwd2FyJun 18, 2021 via Android
7
搬砖的不需要了解楼是怎么设计的
|
 |
ShookJun 18, 2021
8
想起来在前公司的时候，总监、组长对我说的话都是“不要钻技术细节，要多关注业务”。
不过我就是不喜欢 require.js + vue，我就是喜欢心智负担更少的环境，就是喜欢更方便地写代码。 换了公司以后就好多了。 |
 |
qz357Jun 18, 2021
10
所以啊，面试的时候又问造火箭的问题，真正工作的时候要你墨守成规。
|
 |
12
@cominghome 有道理。
|
 |
fkdtzJun 18, 2021
13
所谓的重构，不应该先有团队规范，再去执行吗。
|
 |
exmarioJun 18, 2021
14
最后一句深有同感，特别是现在这个什么都要求敏捷的年代
|
|
exmarioJun 18, 2021
15
感觉现在这个年代，钻研技术获得提升可能是个错误的方向
|
|
16
@exmario #15
钻研技术是正确的，但钻研技术的核心目的是达到更合理的软件工程实现，而不是秀。 最近在栈溢出中看到的评论：“现在年轻的程序员都喜欢用逻辑非常复杂的、高耦合的、难以阅读的代码来解决简单问题以体现自己的能力，这让我感到非常悲哀。” |
 |
xuanbgJun 19, 2021
17
“现在年轻的程序员都喜欢用逻辑非常复杂的、高耦合的、难以阅读的代码来解决简单问题以体现自己的能力，这让我感到非常悲哀。”
@kop1989 这评价真的是过于真实了。。。明明二三十行代码就能解决问题，非要弯弯绕写个上千行代码来实现数十个 bug ！ |
 |
zhangyichentJun 19, 2021
18
我们团队重构都是我拍板，根本就不会让老板知道哈哈
|
 |
ganclJun 19, 2021
19
观《观《向老板提需求被狠批》有感》有感
|
 |
myCupOfTeaJun 21, 2021
20
我都是接手同事抱怨没法改,然后让我重构,我直接重写了(
|
2
Select Language