观《向老板提需求被狠批》有感

[kright]

真实的职场经历往往能引起大家的共鸣，被 V 友 @totoro52 的一句 "永远不要跟老板提系统的改动和重构，他们永远都不会答应的，他们只会觉得 这只会浪费时间和人力" 触动。

本人也是刚入职一家公司不久，7 年后端了，技术马马虎虎，胜在有一些中厂经验。之前搞过创业，也带过团队，后来被人坑了，又回归到正常的工作。 带过团队经历过，确认自己是不适合搞管理的，不太擅长沟通（喜欢有挑战的事情自己做，不放心，把活分配出去总觉得不好意思，没法对团队施压，甩黑脸等等，简单来讲就是心软或者软弱懦弱）只想做好自己的事情。

新的团队业务倒也没有很复杂，但代码不怎么规范有点乱，初来乍到，花了很多心思在优化重构上，结果被直接 leader 各种拐弯抹角，说了很多次，说你觉得是优化重构，其实不过是审美问题，每个人都有自己的想法和喜好，有些人就喜欢一堆 if else 一个方法几百行也没问题。 就总认为我的工作，仅仅是让代码变的好看了，于团队全然没有帮助，甚至会让有些人不习惯影响开发效率。可能他都觉得我是在做无用功吧，连续几周对我的评价都是，不要钻技术细节，要从全局去看。。。。。。哎。

[liprais]

领别人的工资按别人的要求做事呗

[yeqizhang]

我和你第二段是相似的，第三段，如果能提升效率还是可以，没有啥大用处的话没必要花精力去搞的，写好自己的代码就好

[koake]

重构这种事件，如果是小团队的话，还是比较适合在保证进度的前提下进行。如果不是大面积的话，其实大部分重构都是在这段代码实在是看不懂了的情况下才进行的 😂

[BBCCBB]

对的, 保证你产出的前提下再去做额外的事情.

[cominghome]

大部分公司都是业务导向的，纯技术导向的公司真的不多。

那篇文章我也看了，私以为雷军说的那句话还是有些道理的，新员工多看多听多想少提意见，很多事情不是大家没想到，而是推不动。重构可以，收益怎么计算？能体现在你老板的 PPT 里吗？不能的话那对部门也未必是好事。

平时写代码用高标准要求自己就好了，前人写的代码，在不知道他是什么场景下完成的情况下，少评价，除非有 bug

[kop1989]

这里面你犯了一个基本错误。即：程序的重构应该是你们技术团队内部风险对冲的一种举措，为何会捅到上面去？作为一个商业视角的决策者，怎么可能会同意大成本的，仅有技术意义的重构？

当一个重构带来的是额外的成本，而不是收益的时候，重构真的是重构么？

[Y29tL2gwd2Fy]

搬砖的不需要了解楼是怎么设计的

[Shook]

想起来在前公司的时候，总监、组长对我说的话都是“不要钻技术细节，要多关注业务”。
不过我就是不喜欢 require.js + vue，我就是喜欢心智负担更少的环境，就是喜欢更方便地写代码。

换了公司以后就好多了。

[Rache1]

@Shook 🤣 面试的时候再让你去钻技术细节 哈哈

[qz357]

所以啊，面试的时候又问造火箭的问题，真正工作的时候要你墨守成规。

[kright]

@liprais 是的呀。。。可能还是过于理想化

[kright]

@cominghome 有道理。

[fkdtz]

所谓的重构，不应该先有团队规范，再去执行吗。

[exmario]

最后一句深有同感，特别是现在这个什么都要求敏捷的年代

[exmario]

感觉现在这个年代，钻研技术获得提升可能是个错误的方向

[kop1989]

@exmario #15

钻研技术是正确的，但钻研技术的核心目的是达到更合理的软件工程实现，而不是秀。

最近在栈溢出中看到的评论：“现在年轻的程序员都喜欢用逻辑非常复杂的、高耦合的、难以阅读的代码来解决简单问题以体现自己的能力，这让我感到非常悲哀。”

[xuanbg]

“现在年轻的程序员都喜欢用逻辑非常复杂的、高耦合的、难以阅读的代码来解决简单问题以体现自己的能力，这让我感到非常悲哀。”

@kop1989 这评价真的是过于真实了。。。明明二三十行代码就能解决问题，非要弯弯绕写个上千行代码来实现数十个 bug ！

[zhangyichent]

我们团队重构都是我拍板，根本就不会让老板知道哈哈

[gancl]

观《观《向老板提需求被狠批》有感》有感

[myCupOfTea]

我都是接手同事抱怨没法改,然后让我重构,我直接重写了(