场景：为了赶项目进度，你写的代码并不优美（很烂）。你知道，作为 coder，这不是你想要的；作为职员，这也无可厚非； 问题：当你发现一直在赶进度，你也一直再写“烂代码”，你会怎么办？

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

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

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

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

要接受客观的不完美 🤷‍♂️

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

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

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

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

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

要么忍要么滚

这么明显的答案 肯定走啊

业务先上线，这是真理。因为客户和 PM 看不到你代码，至于优化，后面再来，所以代码不优美可以，一定要有维护性和可扩展性

@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 保护好自己身体，别多想。