好吧，我最后选择了 Say GoodBye，因为我看到出路在哪里。。。。

掀桌子走人啊

别勉强自己

代码因为赶进度写的烂，早晚会回来收拾破摊子的。所以趁早离开比较好

公司的代码烂就让他烂吧，反正写的好也不会给你涨工资，改出 bug 你还要杯锅，有技术追求的化可以把代码水平发挥到自己的项目中或者去开源社区贡献点代码。

压时间，就代码烂。为了速度哪有时间考虑那么多。

别加班钱给够还好说，效率低点自己还能另外补课。

@airfling 实际上，我离开时就已经在收拾烂摊子了，而我也真不想和他们一块儿继续收拾了。。。

走人。
这是系统性问题，除非重做系统，或者换一个。

讲道理看你的标题，以为自己在靠 PMP

公司的代码 可维护的确实不多...
功能的迭代,人员的迭代
为了工期与兼容 "不得不妥协"
so,
也许自己写自己代码,才能让自己成长?

个人习惯问题吧。

当自己有着良好的编码习惯，写东西的时候会不自觉的写的更好

有良好习惯之后写优秀的代码并不需要刻意花太多的时间重写

再说了，只要你的代码面向业务，就没有不赶时间的，走哪都一样

这不是 code clean 第一章描述的情况么？感觉这本书完全可以解答你的疑问

你最后会发现到了哪都一样

@NilXuan 我手里的这个项目就是我们一开始开发的,刚开始也是赶进度，一堆垃圾代码，和繁复的开源组件，后来我带人维护的时候花了一年多，才把代码重新整理了一遍，把流程简化和去掉冗余的开源组件。所以不想维护可以趁早走，很烦人的

绝大部分公司都这样，重视代码质量的都死光了

换一家公司 能给你足够时间的公司.
还有就是你为了赶进度而写烂代码的基本原因是你对写所谓优美的代码没有足够的习惯和缺少写代码前的思考.
一个能力达足够的开发人员即使在时间紧迫时也不会写的很烂,
所谓的烂只是在写的时候会想到该怎么写(会加入 todo)但是因为时间的问题导致没办法完善.
在项目上线前会自己完善必须完善的. 不是太重要会找时间完善好再上线.

我的解决办法是这样的：
1. 接到需求后，把你能想到的可能性都和产品对一下确认后只要有存在的可能性在开发的时候都预留扩展点;
2. 开发的时候，尽量的使用设计模式 这个需要根据自己的经验把握尺度，危险点是一不小心就会过渡设计，因为这条很容易导致你 yy 自己给自己加需求，会导致不能按时交付而且也反而会写`烂代码` 而且导出逻辑漏洞， 所以需要谨之又慎

你可以实现的烂，但是代码风格不能烂，注释总该写吧，代码应该好好组织吧，总不能烂到第二天起床就看不明白昨天的代码吧

do what you can,大有大的优雅，小处有小处的优雅

@NaoNao9976 啊哈，自己还处于优良习惯养成阶段，还没达到信手拈来的水平。。。不过你说得对，所以应该先养成这样的习惯！~

3. 如果当前时间确实很紧迫， 那尽可能的不写烂代码 首先实现需求， 因为再好 再优雅的代码也是需要实现其价值的，俗气点说就是需要变现的， 如果不能创造价值，就是一堆字符而已 无用的字符， 之后再找 leader 商量重构 提出具体的重构说明文档

还有就是补充一点啊.
你写好代码都是要依靠项目时间富裕给你时间优化代码的话. 你真的会去优化吗?
如果是这样的话会不会影响项目排期呢.

公司代码烂就让它烂，早晚要崩，快崩之前就跑。烂摊子反正会重做的。

代码写烂了，开始的时候可能会快一些，但是大多是越写越慢，甚至不可收拾

从来没有因为赶时间写过烂代码。编码是开发的最后以换取，实际只占总工作时间的 1/3。
我只见过赶进度用了一个烂的 quick win 的设计，不相信你能从编码中赶出时间来。

@FrankHB 捕捉球

到哪都这样吧
我司鼓励原生前端和 JAVA 后端来写 web 端，结果自然就是 web 前端擦屁股，跟公司大小无关，就是领导层不专业

如果你很在乎你的工作质量，十年后你不会写的很烂。就好像一个画家，开始可能画的很烂，但 10 年后，他可以从任何一个位置画起，都不会搞错比例和细节。

现在省下的每个小时，在五年后都会变成每天杀回来。

后面想通了，一有时间就重构，一定要留时间给自己充电。别人 7 天完成的，你一天就能搞定，剩下就开始充电了。

可以来对安全要求苛刻的企业啊

其实，我是一个程序员

到目前为止，我觉得这个问题是无解的，除了很多小而美的公司，大多数都是这样子，为啥？因为你不赶工赶需求你领导怎么升职加薪？至于代码质量，有升职加薪重要吗？这还算好的，差一点的往往是前面赶工干活，后面赶工擦屁股，最后发现屁用没有，还不如慢慢做，这些问题都是显而易见的，但是这么多年都改变不了，根本上来讲这不是代码的问题，也不是写代码的人的问题，是管理上普遍存在的问题，你换了个公司也是差不多。
我现在对于这个只有两个解决方案，一个是拒绝合适的需求以及工期安排，当所有人都拒绝的时候，是不是环境就会好很多？当然我也知道不可能所有人都拒绝，总会有工贼，所以还有第二个就是把工作中的很多遗憾安排到业余去做点自己的东西。

@jingyulong 我猜你没多少工作经验，但凡有经验你就不会说出 “有时间就重构” 这种话，干的多了你就知道，那是不可能有时间去重构的，有时间也不会有精力去重构，有精力更不敢冒风险重构，赶工的活一旦赶出来，那就是永远都在这样了，bug 能修完都算不错的。

随时重构，比如第一版是垃圾代码，需要在垃圾上加功能的时候就把第一版的垃圾重构掉。
总之可以有垃圾，但是不能在垃圾上堆垃圾。

你会发现哪都差不多的

@Sapp #35 那你尽情猜好了，每个人水平本来就不一样，你就慢慢磊你的代码吧。

另外，表达意见可以，带人生攻击，歧视，就会让人觉得很 low

@jimrok 那这个画家在这十年里一定有选择能让自己画的更好的环境

上班做功能，下班优化代码。

充分理解场景，但不是很同意，追求项目进度就会代码写得烂的因果关系，好的代码结构，开发高效本来就是一个重要的因素。烂分两种，一种是真烂，连基本的规则都不遵守，各种 hardcode，胡乱抽象方法函数等等，这个跟时间没关系，人的问题，还有一种假烂，因为需求会一直在变或者增加，再看前人的实现就感觉各种不可维护扩展。前者需要经验积累，后者像 @posebear1990 说的随时重构是免不了的。个人觉得写代码跟大多数技工是一样的，要用巧劲，不能用蛮力。产出最多的不一定是加班最多的。

copy 过来，能跑就行，又不是不能用

所谓的代码优美对公司的效益来说并不值钱，稳定能跑能实现功能就是好代码，况且大部分情况下你自以为优美的代码在别人看来也是一坨 shit。所以请各位码农不要把自己太当回事。

体现一个程序员的功底和价值的地方不在于写出多么优雅的代码，而是在是否能快速上手其他人的代码，在他人的基础上快速实现功能的迭代。

现在互联网项目的发展方向是服务化，把传统那种大而全的项目拆分成各种小模块由不同项目组团队负责维护，这样能极大的降低耦合、方便维护迭代。真的有某个模块因为技术原因导致项目无法迭代下去的时候，另行组织人员重构该模块就是了。

@q8164305 饿死了吗？

@hyuka 从来没有一个那个时期的画家能够做到任何 “好的环境”。有顿吃的就已经不错了…… 一说创作需要苦难，或许这反而是 “好的环境”？

在不影响进度的情况下，尽可能不写垃圾代码，尽可能重构。对自己要求严格一些，坚持下来，相同时间码出的代码，平均水平就应该能比别人高。

@broadliyn 你这突然启发了我。
这个 “拆分” 就像是一个 supervisor，而一个个小模块就好像一个个进程。
erlang （以及重新发明的微服务架构）强调快速失败重启。
那么可能相比 “无法迭代下去”，不如以更快的 “迭代稍有变慢未能在指定时间内交付” 视作重启信号？
同样如果在连续五个周期内出现三次未能交付就应该主张指定时间不合理或者模块划分不合理。

你就说这是不是写 java 的人的常态吧

一直很好奇国外一般的公司注重质量吗

行业的系统性问题
大多数情况是，还没等技术债积累到不得不优化的时候，业务已经死了
或者是，如果放缓业务优化重构代码，竞争对手是毫不留情的（参考去年 shopee 把阿里 lazada 按在地上摩擦）

如果你不幸遇到了这样的业务，那么
1. 保证自己新编写的代码是可维护的，和已有的垃圾代码减少耦合
2. 下班参与开源项目，自我提升
3. 业务节奏放缓时，小步重构代码

强迫自己尽可能写好，这样才能成长吧

跑路

力所能及的情况下顺手重构， 每次离开时比来时更干净，by “童子军规”

我发现我提升代码质量都是在非工作时间学习而来的，然后在运用到工作上，楼主看开点。

为什么赶进度代码就烂我是一只不明白为什么那么多人都这么说。
赶进度顶多是代码逻辑漏洞多吧，不能说代码结构就烂吧？

最后:
好处, 解铃还须系铃人, 保住了工作;
坏处, 灵魂没有得到升华, 愤恨离职.

写出更好的代码就算是有输入了吗,我怎么觉得还是在输出?

@no1xsyzy 再深入思考觉得就慢慢往哲学方面靠了，以我来看，“好的环境”就是有充足的时间去做想做的事。这里面的环境是为了某种原因不得不花费大量时间写烂代码，这就不算“好的环境”

@hyuka 这里的想做的事我指的是写优雅的代码

都说了是为了赶进度，赶进度的意思是时间不充裕，在时间不充裕的情况下，你没时间好好思考，你没时间重构，你甚至都没时间给变量起一个好的名字，你更没时间进行优良的设计，特别是当你的设计还需要去重构依赖模块的时候。退一步讲，就算做了优良的设计，你也没时间跟团队成员去沟通让他们理解你的设计，于是，你不得不退而求其次，写一些扩展性差的代码，引入一些临时性的 dirty hack。基本上碰见这种快节奏的开发工作时，就是你该离开的时候了，但你下份工作大概率还是这样，除非你已经达到一定的高度，一个别人难以企及的高度，那就另当别论了。

Say Goodbye 也是一种办法，逃避虽可耻但有用。

不过 #43 说的我很赞同，什么是优美的代码，各花入个眼。目前可以量化的评价标准基本上是测试覆盖度和成功率（也就是软件质量）。

除了躲，也可以尝试挑战一下现实，个人拙见是，可测试的代码才有机会提高质量，我们都知道软件设计要低耦合高内聚，知道开闭原则，依赖反转等等理论，但实践的时候，却容易陷入纠结。个人经验是，对你所写的代码都编写单元测试，可测试的代码，基本上都能满足上述理论。（时间紧只写 happy path 也可以）

无论躲还是刚，我觉得都 OK，主要看自己能力了。
就像打大 Boss，自己阅历不足，经验不够，那就去野区打野练级。等经验上来了，再挑战。

@posebear1990 有意思，哈哈

冒昧问下，楼主离职的说辞是啥……说出真正的原因了还是……

@hyuka 当时的全职画家也是白天花大量时间去画些维生的刻奇作（肖像、小动物）。
晚上才是做杰作的时间。
这么说来确实是 “下班优化代码”……

赞同四楼
我就遇到你这么个情况，入职公司接受了一个 php 维护项目，前辈纯脚本式开发的，没有文档，命名不规则，文件命名无迹可寻，各种 include 文件，稍微复杂的逻辑就用十多个 if 堆切起来，我现在找个变量需要 nodepad++文件夹搜索。

近段时间用微框架按照自己定标准重构，扩展了框架一些地方来符合项目数据结构，composer 各种库引入，文件数据结构和 java web 项目差不多，核心代码写了三千多行，但是业务代码我是实在没劲写了，实在是不符合自己的利益呀，有这个时间真的不如刷知乎，你说现在服务跑的好好的，自己重构老板凭什么让你上架？人家只知道我现在服务能跑，没有出问题，反正你写的出了问题，你就倒霉了

至于为什么不写业务代码了，其实把一个微框架扩展到差不多 thinkphp 中型框架还不失灵活性，我觉得我的目的达到了，其他真的是没劲了

@wangfei324017 啊哈，就说项目强度高，没有时间补充新知识呗，我是选导师啊，又不是选老板，然后就离开了。

@broadliyn 你说的非常有道理，公司的利益从来就是和员工的利益不一致的，所以我非常支持该走就要走，管那么多干嘛，不符合你的发展前途，给再多钱也没用

个人经历，凡是代码烂的无可救药的，往往代表项目本身也有其他问题。
这些项目都凉了。

事实就是产品只看效益。

尽量在添加功能不要太“重”

像 50L 所说的小步重构

这就是一般程序员和优秀程序员的区别。优秀程序员能够在进度的要求下写出优秀的代码。一般程序员就只能写烂代码，好歹能意识到自己正在写烂代码而不愿妥协。

觉得这就是我现在的场景：想开发自己的个人独立作品，又想找 Android 开发工作，一方面指责自己代码不好看，想重构，一方面又希望能赶紧上架有个工作先吃饭。

先完成再完美

要求老板涨工资

已经麻木了，烂代码就让它烂下去吧，如果追求完美这项目还做不做了。当然烂到不可接受就跑路吧。

Archtect 为啥大部分从外面大公司来，啥原因？

感觉也是对应的问题 cpp 的工程引用混乱 没有模块概念 上帝类很多

我选择走，到后期我完全不想看之前的代码了。虽然组织过一次重构，但根本没时间进行下去，项目进度太赶，导致一个个优化的想法胎死腹中。
最终无奈离职（ ps，离职当然还有其他原因）

我的第一段程序员经历告诉我，代码就是妥协的艺术，要和时间、金钱赛跑就不得不做出让步。可能这里高手比较多吧，混口饭吃，别太较真

普遍情况是大家不会在意代码质量，并不代表没有在意代码质量的。

就是因为少，才要好好找的嘛。就跟妹子虽多，女神很少一个道理。

1. 如果一个团队长期处于”时间紧，任务重”，需求本身排期问题，考虑一下这个团队的定位和长期发展，以及你自己的职业生涯规划，是继续熬上到管理还是选择换团队甚至公司
2. 如果是短期或者间断性出现，考虑你的团队技术栈和能力，方向是否存在问题，这一般是可以改善的。一般来说可以从架构拆分，抽一层替换实现重构，完善基础设施提高效率入手，需要一定时间，但是可以保证上层业务很少受影响，不会出现雪崩的问题
3. 业余时间和工作不多的时间，学会总结反馈自己的成长，可以写博客，写 Wiki，写技术书。不然很多东西你其实在实际问题中解决了，但是随着时间推移又忘记，这就属于你的个人能力的损失了
4. 持续学习，可以考虑参与领域相关的开源社区贡献代码，阅读他人的源码，可以学习比较厉害的人的分享和 Keynote，保持自己的竞争力属于业内第一战线，就算日后有人也有底气寻找更适合的地方

@fuermosi777 我要做一名优秀的程序员！现在因为我无法做到，所以选择了离开，继续积淀~因为感觉不离开吧，时间和精力都支持不了我走向优秀，不知道是自己没有合适的方法，还是客观情况就是这样。。

@lizhuoli 虽然写博客比较占用时间，但是我还是坚持在写~我赞同你的说法，特别是个人能力损失；回顾自己的 4 年时光，将近 1/4 的时间算是损失了；但转念一想，塞翁失马，焉知非福，况且在学习的过程中，也提高了学习素养啊（好吧，我是在安慰自己）

某种程度上说，写烂代码是正常。
首先，项目驱动开发，你要首先保证的是商业目标的实现，写代码的时候总会因为经验、开发速度、实现效率等做出妥协，这是客观真实。
其次，代码是不断迭代优化的，还没人能一次写完就可以优美的跟诗一样。

要接受客观的不完美 ♂

@zjsxwc 嘿，之所以意识到自己的代码不好，就是因为那本《整洁代码之道》。。。

@koodai 是的，赞同“接受客观的不完美”；我第一次看《整洁代码之道》，然后就不敢写代码了。。。因为感觉作者就是看着我写的代码将反例。。。。然后那段时间就去学习设计模式了。。觉得掌握了设计模式，写的代码会好一些

我现在也面临这个问题，最实际的方式就是小步重构，然后等到每次迭代版本以后的两三天缓冲期进行调整，但是平时写代码的时候就得注意一些，不然缓冲期不够改的，我还是很享受这个调整的过程的.

哈哈哈，你这头像，暴露年龄啊，前段时间又翻了一遍整洁代码之道，还是要经常翻翻看看的，毕竟时间久了，难免会忘记一些东西

@sdushn 吓得我赶紧换个头像；温故知新，谢谢提醒~

要么忍要么滚

这么明显的答案 肯定走啊

@NilXuan 嗳，咋换了，哈哈哈，我都想重温一遍围棋少年了，哈哈

这不是程序员的问题，是管理者的问题
所谓看代码，版本上线的时候是团队资产，上线后维护的时候是团队的负担
要么业务是土豪不在乎，要么是 PM 水平不够

我都是在未来的版本开发里面捎带重构的事情。很多时候向前不懂技术的管理者提出重构要求就会陷入无止境的扯皮中，所以我都是直接在评估时间的时候把重构工作算进去。

@broadliyn
优雅的代码对公司有价值的，尤其是离职高的公司，一个项目往往有很多人接手过。屎山一样的项目，后面的人想要在上面加新功能都困难，重构的成本又更高。

特意登录来回复 情形类似 深有同感

以至于有时候我会想 是不是靠关系拿到的项目都是这样烂

亲手写出 shi 山 但是无可奈何... 别人指责你技术烂 都没有还口的空间

甚至都没有测试 全程自测 频繁变动以至于很多东西都无法稳定

因为大部分公司都不够“大”无论是公司本身的规模还是业务项目的规模、周期、要求。因为不够大，所以体现不出可重用、可维护、可扩展的好处。

比方说写一段糟糕的代码要 4 小时开发+4 小时测试。假如每次维护需要花 2 小时修改+测试+到处粘贴，那么项目生命周期中，开发+维护 12 次也就 32 小时。
你写一段“优美”的代码可能光是开发就要 12 小时，测试 debug 要 36 小时，每次维护半小时，那么维护 12 次就要 54 小时。
对公司来说 32<54，自然选糟糕的代码。

但如果同样功能在一个大项目中，糟糕代码由于复制的地方变多导致每次维护要 4 小时，优美代码每次维护变成 45 分钟，生命周期中维护次数变为 48 次，那么糟糕代码耗费 200 小时，优美代码耗费 84 小时。显然优美代码就有优势。

另外别忘了，即使是看似长期的产品（比如某电商网站），也有推倒重构的可能，所以烂代码适用的场合还是很多。
只有那些维护期限超长（比如 ERP 系统）、可用性要求极高（比如金融行业）、安全要求严格的项目，才能体现好代码的优势。然而这类系统现在似乎也通过降低客户期望来降低要求了。

如果实在没时间写好的代码，至少在关键地方写两句注释。

年轻人，定位错误

我国 IT 从业人员，别自我感觉良好，因为是科技人员。我国各大 IT 公司本质是劳动密集型企业，买别人的硬件+github 拿别人的代码，然后代工做应用，成功的主因是：wall+13 亿人口的市场。

IT coder 和代工厂里的厂妹本质没啥区别。

就这地位，就别想啥代码并不优美，啥创新之类的了。1 拿好工资，2 保护好自己身体，别多想。