@qs 一切根源在于领导的"这个功能明天一定要上" ---------------------- 单纯的讨论这句话，是不负责任的。 因为你们没出钱，没感受到压力。 等哪天程序员自己出钱组建公司，一定比领导更狠。说不定就变成了：我今天就要上，干不完不许走。

@paradoxs 1. 我认为在这里讨论这些的确是不需要负责任的 2. `等哪天程序员自己出钱组建公司，一定比领导更狠` 领导和程序员的角色不冲突, 重点在于自上而下的决策压力. 一般情况下, 程序员(执行者)是面临来自产品经理(规划者)的压力, 产品经理面临来自上级老板的压力(决策层) 至于最上层是因为 资金压力、业务压力、外行领导内行还是资本家最朴素的心思, 确实不该是"程序员/下层员工"该考虑的事 而你表述的所谓这种"一定比领导更狠", 更印证了这种会导致重构无法成立往往来自于最上层的压榨

"预知需求” 是需要的，但就和天气预报一样预报越久偏差会越大，而且成本也越高，老板耗不起让你做一个能满足百年一遇需求的方案来。 所以一切都是取舍，尽可能在通用和特殊之间达成一个平衡。 但随着时间和人员的变迁，如果没有持续的注入新的活力，大多数产品终会有掌控不住慢慢腐化的时候。

linux 怎么就没腐烂呢

先生，您这样是要加钱的

除了“这个功能明天一定要上”，还有一个应该也是很重要的，“只要能跑就行”。

@metalvest 早就烂了，无非是烂的不只是 Linux 自己。

有两个办法让代码不腐烂：每新增一个需求，就把代码重构为符合新需求+旧需求的样子。或者，你可以什么都不写，没有代码和需求自然没有腐烂的代码。 至于那些不为未来做假设的……我提醒你，你最好不要为自己的懒惰找借口。如果你不考虑未来如何重构更便利，那要么你会在每次重构时付出巨大代价，要么，你就会干脆放弃重构，代码自然就是“烂”掉的。

因为写的好不多给工资, 写的不好到时候也不用你改

需求变更可以接受。每次做完之后再做对应重构和总结，可以尽量减缓和避免这种情况。但是看是否给你时间了