千万不要相信码农说的，任务太紧，没时间优化代码

• 資深大佬 : lepig

  哈哈 主真的是来“对”了地方

  不出问题的代码，优化完了谁测、测试有时间安排测试么。优化完了导致了业务故障谁负责，优化需要开评审会么。谁来负责牵头这个优化的排期及跟进进度。
  啥都没说 就让人优化

  der

  对了，前排出售瓜子饮料矿泉水了喔…

• 資深大佬 : ruike007

  没业务需求推动谁喜欢没事找事

• 資深大佬 : ypzhou

  上+1，优化完了谁测、测试有时间安排测试么。优化完了导致了业务故障谁负责。

  别说优化了就没 bug 了

• 資深大佬 : KaynW

  难道这种方法不是性价比最高的方法吗

• 資深大佬 : smallyu

  把代码写的漂漂亮亮的能涨工资不

• 資深大佬 : miniwade514

  感觉此帖可以预订热榜了

• 資深大佬 : chickenJuicer

  除非代码具有完整的测试代码, 否则不建议针对线上代码优化, “又不是不能用” 这句不负责任的话其实另一面是对产品稳定性的负责

  写的时候做好解耦, 大概率后期不用做大面积代码优化 /重构, 除非业务逻辑动底层了; 其他小优化顺手可为, 就看懒不懒了;

  如果业务逻辑没动, 但是代码还需要大面积优化, 那么可能是最开始代码设计不行

• 資深大佬 : seanxx

  你来测,你来回归,你来评审,出问题你背锅

• 資深大佬 : chotow

  到点下班走人有问题？闲得蛋疼不走人？

• 資深大佬 : php01

  实现任务了事不很好吗？
  嗯？
  你要实现不了任务？还是不能了事？

• 資深大佬 : also24

  以偏概全 [ yǐ piān gài quán ]

  释义：
  以：用；偏：片面；概：概括；全：全部。用片面的观点看待整体问题。

  以偏概全的近义词：
  一孔之见 以管窥天 一概而论 一叶障目

  以偏概全的相似词：
  一棍子打死 片面 一棒子打死 概全 不客观 有失偏颇 绝对化 偏盖全 不够客观 失之偏颇 偏颇 片面性 主观臆断 偏概 一竿子 片面化 一概而论 个人偏见 全盘否定 主观片面 断章取义 一叶障目 地域攻击 地域黑 就事论事 偏激 地域歧视 一叶障目，不见泰山 一叶障目不见泰山

• 資深大佬 : ferock

  @smallyu #5

  当前公司，不能
  职业生涯角度，能

• 資深大佬 : solee

  哈哈哈 奋斗者~ 热起来！

• 資深大佬 : hoyixi

  这和公司环境有关，小作坊制度的公司，就别妄想出个鹤立鸡群的，真出了，多半也被枪打出头鸟

• 資深大佬 : gkiwi

  小的优化都是随时随地的做，比如多增加几十分钟工作量，抽离一点可复用的东西，利人利己。
  大块的优化，看用户收益，看开发人效，看影响方的收益，可以单独起技术项目来推进。

  不太理解很多上的心态。即使小公司整体不考虑大块的优化，自己搞些小的优化自己舒服不好么？

• 資深大佬 : charlieputon

  你是个什么

• 資深大佬 : EminemW

  你应该不是开发。业务不紧的话，可以做到你说的吧，但是到点下班就回家有什么问题（完成当天工作的前提下）。

• 資深大佬 : james122333

  比较算吃力不讨好 毕竟每个人都有自己的人生 不算功绩就更糟糕了 真有这需要 一开始就要处理好了

• 資深大佬 : wysnylc

  压迫,都可以压迫

• 資深大佬 : xuanbg

  所以呢，大多数程序员都是把一年的经验重复了 10 年，然后发现前面没路了。南郭先生总有混不下去的那么一天……

• 資深大佬 : mayfly233

  哟，又是一个月几千块的精神股东来了？

• 資深大佬 : chendy

  主是刚工作么，自己有想法想提高是好事，但是要小心不要给别人擦了屁股让自己掉进尴尬的境地
  这个行业不好好写代码，或者根本不知道怎么好好写代码的人很多很多，大家都是混口饭吃，不要要求太高

• 資深大佬 : jingcoco

  随便聊聊。后面来的开发要填前面所有人的坑？感觉维护别人代码的经验是:不要重构或者改之前的代码。。。。然后代码就会越来越不可维护或者成本太高。。。。国内国外的大厂小厂都是一样的。。。。

• 資深大佬 : labulaka521

  公司老板？精神资本家？

• 主 資深大佬 : hbolive

  @mayfly233 不是精神股东，但是出了问题，别的部门首先找到我，我一般会定位下问题所在，一看问题原因，有时候难免火大（这么简单的问题，也会错）。。

• 資深大佬 : MengiNo

  除非公司有非常完善的 devops 及测试体系，本来就很规范，或者有个非常支持的领导推动，否则这么做就是引火上身…… 个人早年也是这样骂一个个代码和 shit 一样。真正改了你就发现，要么需要的时间远远超出你的想象，搞了很久拿不出实质上的成绩。要么一改就错一错就背过。最终越弄越没意思逐渐丧失动力。
  这个个人觉得是一个团队或者公司管理的问题，真不是几个码农一厢情愿的什么自我提高啥的能解决的。当然你可以认为我水平太次一直在最底层，无法站在 leader 的高度看问题。但是你说到技术追求什么的，有些事情真的不是仅仅靠技术能解决的，要有一套完整的规范进行保障。不然那些正儿八经学管理的，真以为是文科生混文凭的专业么……

• 資深大佬 : Octopvs

  你觉得很简单都会错,但开发可能不熟悉业务,不熟悉的话再简单都会错.代码除非是自己完整写下来的,不然不会动,否则牵一发而动全身,改多错多

• 資深大佬 : MajestySolor

  资本家，精神资本家，员工，罗生门又开始了。

• 資深大佬 : fffang

  底下员工浑水摸鱼，新业务也不好好架构，不好好写，难道不是你的问题？

• 資深大佬 : james122333

  这就是任务不是吗？

• 資深大佬 : zjyl1994

  改屎山是需要莫大勇气的，挺好的东西没需要你自己优化，搞完了加钱么?不加吧？那优化崩了呢？你是不是得挨批？重大生产事故以后是不是会被降职甚至开除？你算算收益就知道了。
  还有很多东西你觉得没啥，打开一看一堆逻辑，删哪个改哪个？你能确保和设计的要求一样吗？一旦漏了，客户电话打过来也吃不了兜着走。没事动能用的代码干嘛。

• 資深大佬 : raymanr

  不过主骂的也对，我们公司的开发，做四个页面（页面内容就一个 form 一个 table ）做了两个多星期，出来的页面控件溢出，弹出窗口没有关闭按钮，产品名称 overflow 的部分被隐藏，我看到这种东西我能说啥子？

  再加上提需求的也完全搞不清楚自己需要的是什么

  算了，有工钱拿，不加班就行了

• 資深大佬 : xiangyuecn

  钱到位，加班到凌晨都冒的问题。

• 資深大佬 : Narcissu5

  说到心坎里了，花了很多精力优化代码，结果没人在意，反而是过程中出的一些问题搞得人尽皆知

  优化这种东西，除非上层站台否则真的就是又不是不能用

• 資深大佬 : deef

  涨工资吗？钱给够，我连麦当劳那个新品都不去吃都能给你改。

  钱不给够，那谁管你… 又不是自己做着玩的项目。

• 資深大佬 : warmsun0220

  码农跟农民的最大区别就是，农民已经是给自己干的了，码农还是给老板干的。东西是老板的，体验是用户的，工资才是自己的。第一遍能好好实现就不错了，别说后面优化了。这也是大部分人只是码农，不是张小龙的原因了。

• 資深大佬 : ayavvv

  优化这种东西，是从上往下推的。如果你跟了个不在意技术细节的老板，做了等于没做。那干嘛还要做。

• 資深大佬 : missdeer

  只能说主的眼界限制了你的想像力。我来告诉你什么才叫公司不忙：
  我在的公司世界 500 强，做的项目规模一般，客户端 windows 版用户 3000 万，其他平台的也有但相对 windows 版可以忽略不计，这是背景。
  我们 PM 会长期有一大堆的特性，列在表里要让开发做的，每年发两到三个大版本，定好发布日期，定好要做的 user story(其中大部分是 PM 列出来的特性列表里挑出来的，还有小部分是 technical debt，就是重构，优化什么的)，到发布日期前的三四个星期，发现 诶，时间不够了，这些 US 做不完了！照国内大部分公司的尿性应该鼓动全员加班了吧，而我们这儿照样 6 点走人，要赶班车的，临时有事的照样提前走人。至于那些完不成的 US，砍掉！下个版本里再加！这才是“公司不忙”的正常做法。
  所以主完全是一厢情愿，把优化重构代码就是正常工作的一部分，要列到工作计划中的，排到项目管理日程中的，而不是指望员工加班去解决。

• 資深大佬 : missdeer

  补充：我们在排每个版本要完成的 user story 中，technical debt 必须占一定的比例，不能全部是 PM 列出来的特性需求。

• 資深大佬 : fewok

  千万不要相信老板说的，公司没钱，他可以卖房卖车贷款

• 資深大佬 : lewinlan

  主说得很中肯，支持一下。

• 資深大佬 : Solael

  @missdeer 是的正常的开发流程应该是这样的，重构优化应该专门的 sprint 去做。烂项目才无规划一手抓，又要按时上线又要代码优雅根本不现实，业务是不等人的。

• 資深大佬 : oneisall8955

  有时间我确实会优化，经历了优化自己写的模块，美滋滋

• 資深大佬 : V69EX

  看着上的回复，我终于明白，为何现在的国产应用大多是极臃肿、耗资源了，反正都只想着能跑，跑起来符合产品的需求就 OK，根本没想精益求精之类的……这也许就是快速迭代开发年代的常态吧……:-D

• 資深大佬 : zhangyangkam1

  很正常，谁不喜欢闲着呢。没人去推动，想要靠员工自己主动去优化或者说重构根本不现实。而且你也说了钱不多，人家也就图你个清闲了，怎么会去自讨苦吃呢。

• 資深大佬 : beginor

  一说到代码优化，怎么就不是个路大神各显神通了呢？完全不是 V2 个路大牛的风格呀

• 資深大佬 : Mai1me

  一直强调公司不忙，是不是准备裁员了

  人变少 工作量 自然 增加了

• 資深大佬 : james122333

  @beginor

  政治问题 显了一通在不同环境就什么都不是 是人都不想把命卖掉是真的 底层嘛 好做事比较重要

• 資深大佬 : lscho

  说白了就是给人家开多少钱工资，人家干多少事，如果嫌他干的活少，开了就行。。。自己招的员工什么水平自己心里没点数？如果是很有责任心，技术水平高，公司愿意给人家相应的工资？这和忙不忙没有什么关系。

• 資深大佬 : raymanr

  @V69EX
  臃肿这个问题还真不是程序员的锅。。。

  产品什么都要往里面塞

• 資深大佬 : wangsd

  看公司，公司没这方面的安排不会做，自己独自做影响进度还要被说，完全就是吃力不讨好，吭哧吭哧弄了好久，谁在乎呢。

• 資深大佬 : dxgfalcongbit

  都一样，据我观察大部分机械工程师也不会主动优化设计，基本都是实现功能就交差了。

• 資深大佬 : jaynos

  在不影响进度的情况下, 自己花时间完成了一个接口从 0.5s 优化到 0.1s, 订单吞吐量提高 100 倍. 你不说的话, 没人会知道这个事情. 主动在周报中说明自己完成了这个优化, 老板可能的想法是”这人工作不够饱和啊, 下周多排点活”

  而且很难保证优化之后的代码不会出现隐性问题, 到时候出问题是谁背锅还用说嘛..

• 資深大佬 : shiji

  个人体会
  一个是如果公司人员流动比较快的话， 大家对代码不能够深入理解 ，当然也很难深度优化。

  再一个，这种优化风险大，很容易造成新 bug 。尤其小公司，测试覆盖不足，对于需要稳定运行的业务来说，多耗费一点性能没事，搞出 bug 就是你的不对。员工不会愿意冒这个风险。

• 資深大佬 : yeqizhang

  到点下班不代表不忙，我之前刚入行的那个公司，那一年多基本上每天工作七个小时，那是实打实的每一刻都在忙着开发，除了春节假前有一天，领导也不在了，就摸了下鱼。
  项目太乱的话，我个人觉得优化一下，可以把项目搞的好一些，也利于后续的开发。
  但这种事，没时间的时候，要么开发自觉用自己的时间去做这事。
  要么，就是领导意识到需要优化，安排个时间去做，这也可以减少开发优化项目带来问题时的顾虑。
  你是领导的话，把开发新需求时间压缩，腾出时间去安排呗！有需求任务开发，又想着让开发自己主动去优化！不如每次代码审查找出问题

• 資深大佬 : afx

  同意 26 观点，目前也在维护一坨屎一样的代码，但是即使再看不惯也得忍，尝试改过很多次，几乎每次都有致命错误，我只改了一行代码.gif

• 資深大佬 : defunct9

  最近的经历让我明白一个道理：
  做多，说多，错多
  不做，不说，无错

• 資深大佬 : helloworldgo

  你是部门老大 你不牵头拉资源来做 让程序员自己弄？有问题你背么？优化好了你给人家加工资么？你才是摸鱼的那个吧

• 資深大佬 : veike

  我特别想把我的代码优化一下，但是需要时间啊。我看组里的写代码一把梭啊，那我也只好一把梭了。写代码从来不设计的，只是要把要的数据调出来就行了。
  前阵子刚来的时候组长要把以后的接口按 restful 设计，接口搞到一半的时候才发现前端压根都不知道 restful 是啥，只知道原来是用 post，get，现在用 post,get,delete,put,patch 。比如说，写了一个 /scores/{id}这样的接口。id 应该对应的是 scores 这个“资源”的 id，但是前端传参数的时候，说这个 id 没啥用，组长也当场说这个 id 传 userId 吧，因为 scores 的 id 根本用不到。组长跟我说要设计成 restful 风格的接口，但是组长好像对 restful 的理解的不太到位，因为我个人认为 restful 最重要的是资源这个概念，看这个 URL 就知道你这个接口是干嘛的，传 userId 有歧义，不符合 restful 的规范。(当然我的个人水平也是个半桶水，所以我当时想了想，说，那行，就传 userId 吧。)

  我们公司还有一个问题就是，不写文档。因为觉得写文档花时间，功能更新代码更新文档也要更新，更新文档也得花时间。我觉得这在小公司是普遍现象。包括我和我的朋友也聊过这事，他说大部分公司都是这种情况。除非公司比较大。

  有时候现实情况就是这样，技术能力有限，想把技术搞好只能搞到那个样子。（当然公司的项目很多地方还是有可取之处的，包括我的组长，站的角度不一样自然考虑的事情也不一样。）做为我个人来讲我肯定是想把代码写好的，但是组长或者再往上要考虑时间问题。
  其实我的很多想法都是为了项目更容易维护，写代码不考虑以后维护的话，这个项目终究有一天会维护不下去，到后面会浪费更多的时间。

  这只是我个人想法。具体要看实际情况。

  另外我说一下加班问题，我们公司不鼓励加班。加班没有加班费。这和我原来的公司是一个鲜明的对比。
  原来的公司就是不到 7 点你是不可能走的，我基本都是在 7 点半。 我个人觉得加班真没啥必要，如果不是工期特别赶，尽量不要加班。因为项目不着急还要加班，加班就只是在消磨时间，反正也不能早走，那就慢慢磨时间吧。
  倒不如工作时间效率高一点，精力集中一点。 而且人毕竟还是要生活的。如果每天下班都看不到太阳，出了公司大门永远面对的是黑夜，这种生活方式我是接受不了的。

• 資深大佬 : linZ

  项目代码已经烂了，就不会有人用好的方式写了

• 資深大佬 : mazai

  你知道改恶心代码有多难吗？你知道牵一发而动全身的难处吗？最重要的是每个人的水平不一样，所以写出来的代码参差不齐。优化代码是需要时间的，你以为说优化就能优化了。。。

• 資深大佬 : Arrowing

  主说得没太大问题，就是标题起得太冲。
  大家进来就跟你是对立面了，怎么可能还能和你好好交流，你都是部门负责人了，说话不能这么不负责任啊，一竿子打死一群人。
  对了，我也是码农。
  正常讲，确实业务过于繁忙，没时间优化代码，但是我个人有代码洁癖，有时间还是会优化的，当然，前提是不能出现线上 bug 。

• 資深大佬 : chihiro2014

  不要以自己来要求别人。这点很重要，除非你乐意全部自己写，但是事实证明没人会干。而且讲句不好听的，怎么快怎么来，你后端代码写的再烂，实现需求才是第一。连上线都没法上线，谈什么优化？而且大部分人看的都是前台，前端做的好看，谁管你后端逻辑，根本没人去看。

• 資深大佬 : Erroad

  程序员怎么干是程序员的事，在我看来并没有影响你什么。如果出了 Bug 是你先定位，你就想想为什么要让你定位，你觉得这点上吃亏了就说这个

• 資深大佬 : justinkls1994

  在技术社区讲这番话，注定要被锤爆，心疼

• 資深大佬 : newmlp

  既然优不优化都能实现一样的功能，为什么要多出时间去优化，摸鱼他不好吗

• 資深大佬 : wangyzj

  核心问题
  “公司本来工资就低”

  所以这些钱就值这些代码

• 資深大佬 : chinvo

  屁股歪了

  你就是部门负责人, 也不过是给老板打工.

  先不说”码农”这个称呼的问题, 既然你是部门负责人, 如果要强推新标准自然要自己先上手带头做.

  没人带头的情况下, 自然是之前怎么样还是怎么样.

  再说了, 做好本职工作就完事儿了, 想提升自己也没必要通过给老板创造更多价值来提升.

  按时下班回去读 SICP 和编译器原理不好么.

• 資深大佬 : fansangg

  优化什么的肯定都是闲的实在闲，也许看了看别人的项目，发现，“咦，原来还能这么搞”，然后“优化”一把。

  然后个人还喜欢闲着的时候把自己的代码整得“高深”一点，给以后接盘的人提升一下门槛。

• 資深大佬 : charlie21

  这是一个只给懂的人写的答案

• 資深大佬 : labulaka521

  码农？那你是什么？老板的一条狗吗？

• 資深大佬 : as5739

  你花时间优化代码了，领导一看不出效果，二会觉得你是不是没事干了。
  我这小公司甚至连改 bug 不算在任务量里，说谁让你们写的功能有 bug 的呢，哈哈哈

• 資深大佬 : jugelizi

  现状如此。
  你 bug 多 解决的多 你就是项目功臣 顶梁柱
  你简化代码 提升性能 谁看得出来

• 資深大佬 : wsseo

  优化冒险，很多时候测都没测。

• 資深大佬 : wangkun025

  代码我一个人写的。因为断断续续写了几年，我也懒得优化。
  今天优化了，明天需求又变了。
  能用就用，不能就拉倒。

• 資深大佬 : xiaxiaokang

  代码可以很好，优化也可以很棒。
  那么问题来了：请问公司能给我们提供什么？

• 資深大佬 : xiaofan305

  下属的工作问题，是管理者的责任。你提到的优化例子，甚至可以认为是“实现方式”不一样，毕竟每个人对优化的理解不同，也许人家理解的优化是怎么快怎么来。
  可以把你看不顺的地方挑出来，加上对应的最佳做法汇总起来，形成“规范”或者是“风格”之类的东西。以后新员工入职还可以用来培训。你不愿意就当我没说。
  不过林子大了什么鸟都有，不能强求每个人都有所谓的“代码洁癖”。
  P.S 美剧《硅谷》说到空格键和 tab 键之争

• 資深大佬 : nuk

  能测试就不错啦，我写完代码，都是老板问，你有信心能上么，我说估摸没啥问题。。就直接上线。
  瘫过好几次，直接在线调试。。

• 資深大佬 : massacreformash

  整天想着公司能为你提供什么
  我想说：优化代码难道节省的不是你自己的时间❓

• 資深大佬 : tgy3313

  有时间在这里一棒子锤人，不如和同事多交流交流，管理方面的事貌似来错地方了

• 資深大佬 : alw

  说到底就是，没有安排合理的时间来给你优化？ 只要排好期，我优化 N 版都行。什么？让我自愿加班优化？
  下班时间给开源项目贡献不好吗？

• 資深大佬 : xianxiaobo

  不在于可不可以优化，在于有没有必要优化。

• 資深大佬 : balaWgc

  我也想优化，一个是优化很可能并没有太大的效果，另一个工作量也不允许我，而且领导不牵头重构，自己做了确实并没有什么绩效作用，有这时间好好学习，重构自己的开源项目都好啊

• 資深大佬 : lepig

  看了主的追加，我觉得你想要的应该是 CodeReview 。 既然是部门负责人，那应该是你要牵头做这个事了。

  主多次强调公司闲，但是公司清闲和主动帮优化代码是两回事。所以说在代码上线前进行 CodeReview，不合格的代码或者建议优化的代码早做发现，早优化不是更好么？

  最后，希望主不是那种只会动动嘴，吩咐一下就完事了的领导。任务下来了要和开发人员沟通和探讨下实现逻辑和思路，让他们觉得你也很重视这件事。一些事情的前置工作你可以先做好，给大家做个榜样。我觉得领导最有魄力的地方就是让手下的人信服。

• 資深大佬 : zhang77555

  既然是管理层那就做 code review,不通过不给提交就是了

• 資深大佬 : pmispig

  千万不要相信等我有时间再优化一下

• 資深大佬 : softtwilight

  最好的管理就是找到最合适的人，不是每个人都有代码洁癖，觉得写好代码是特别重要的一件事。真要去优化，都会多多少少做出一些优化，但部分人会觉得不重要，没必要。

• 資深大佬 : hellofrank

  @Narcissu5 同意

• 資深大佬 : nianyu

  优化公司的项目 自然需要公司单独提供优化时间

• 資深大佬 : hellofrank

  @defunct9 跟企业文化有关

• 資深大佬 : enenaaa

  代码优化，性能优化，功能优化是日常工作的一部分， 需要列入开发计划找专人负责的。主作为负责人都没这个意识， 还想啥呢？

• 資深大佬 : casillasyi

  讲一个我自身的经历，有个项目请了一堆外包来干活。他们的代码确实相当飘逸，if else for 那真是遍地开花，没有所谓的对象，全是 map 里面的 kv，比如插入数据库的字段：map.put(“user_name”,value)，有多少字段就有多少次 put 。这已经不是洁癖的问题了，这是他们一撤场我们几乎没法维护的问题，能硬编码的地方绝不优化。很多人说给多少钱干多少活，嗯，所以你就一辈子适合干这种活。

• 資深大佬 : raptor

  作为管理者，难道不能把优化也作为工作任务来安排？优化成果能不能作为业绩考核？优化后增加测试工作也要算工作量，不然出了问题算谁的？
  实在不行换人啊。

• 資深大佬 : zencoding

  归根到底，节奏问题

• 資深大佬 : yl666

  建议：把这些码农全开了，多招几个 P7+，保证代码质量跟源码一样 ：）

• 資深大佬 : hjw45611

  归根到底，功能写完后测试没 bug 了，优化后谁测试？万一测出 bug，测试又会觉得你闲的没事瞎改代码，你给他讲优化，他得把你优化了

• 資深大佬 : neptuno

  你要么就规定好加班制度，发好加班费，制定一系列规范的开发、测试流程，而不是来网上吐槽，管理人员不推动这些，谁来推动？

• 資深大佬 : augustheart

  我手上的某个项目，全程我自己和产品两个人主导，确实是碰到没时间优化的问题。因为昨晚这个项目，接下来我要做别的项目了。
  优化不是说优化就优化。优化首先要考虑影不影响其它代码，然后涉及到一堆功能的测试。没有一段时间全身投入很难搞，然而问题就在于我并没有全身投入的时间……
  加班要能弄我早弄了，实际上就是用那零碎的加班时间不但没效率，可能最后手上只会留下一个支离破碎的项目，就算运气好优化完了，最后和线上代码一 merge，可能又发现完蛋了，冲突的地方太多了……