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

[hbolive]

没办法写得像一坨屎，这类的言语。。

我们公司，自己的产品，二三线城市，岗位实际很闲，下班到点走人，有任务来了也从来不赶着做。。 有码农若干，包括以前来来去去的，也是不少了，但实际上没一个人说，会把自己代码优化好，都是怎么实现任务了事。 做完了测试也是大概测一下就提交，等出了问题（ bug 或者性能上的）再改。

[mayfly233]

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

[chendy]

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

[jingcoco]

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

[labulaka521]

公司老板？精神资本家？

[hbolive]

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

[MengiNo]

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

[Octopvs]

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

[MajestySolor]

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

[fffang]

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

[james122333]

这就是任务不是吗？

[zjyl1994]

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

[raymanr]

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

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

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

[xiangyuecn]

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

[Narcissu5]

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

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

[nadoo]

同情楼主，v2 环境越来越恶劣了，屁股决定脑袋很容易，换位思考却很难。楼主面临的问题是公司给的待遇不高，招到的大部分人对技术没什么追求，有追求、有本事的，就算涨薪可能都留不住，人家会用脚投票选择去更大的平台。公司文化和老板的愿景、公司的业务形态有很大关系，要改变需要耗费巨大的精力，希望楼主顺利。

[deef]

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

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

[warmsun0220]

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

[ayavvv]

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

[missdeer]

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

[missdeer]

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