为什么代码会腐败？原本好好的代码是怎么烂透的？

[muchan92]

以前只是人云亦云地附和“技术债”，没细想，最近发现“需求变更”才是根源。

例如，领导说我们养个动物吧，比如仓鼠，然后你搭了一个小窝，结果领导牵来一头大象，你要么把窝改得不伦不类，要么拆了重盖。

这种需求与架构的不匹配，就会把原本良好的架构拉扯得稀碎。

浅聊一点技术债是怎么产生的？它可能是需求变更中一点点积累的，也可能是突然离谱需求导致实在没法适配的。

开发者面临的困境是，只能设计出符合项目最初需求的合理架构，没办法预知未知需求，但“需求变更”既合情合理也是常态。比如领导可能有一天会把大象换成鲸鱼。

所以，代码是注定会腐败的吗？

按常规思维来说是的，因为需求会一直变。但这也刚好暗示了应对方法：既然需求肯定会变，那么找到一种能适配需求多变，并且不会破坏已有代码的方法就好了，一种始终具有稳定性的方法。

[qs]

@paradoxs



1. 我认为在这里讨论这些的确是不需要负责任的

2. `等哪天程序员自己出钱组建公司，一定比领导更狠`

领导和程序员的角色不冲突, 重点在于自上而下的决策压力.

一般情况下, 程序员(执行者)是面临来自产品经理(规划者)的压力, 产品经理面临来自上级老板的压力(决策层)

至于最上层是因为 资金压力、业务压力、外行领导内行还是资本家最朴素的心思, 确实不该是"程序员/下层员工"该考虑的事

而你表述的所谓这种"一定比领导更狠", 更印证了这种会导致重构无法成立往往来自于最上层的压榨

[kaneg]

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

[metalvest]

linux 怎么就没腐烂呢

[strobber16]

先生，您这样是要加钱的

[vultr]

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

[iseki]

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

[iseki]

有两个办法让代码不腐烂：每新增一个需求，就把代码重构为符合新需求+旧需求的样子。或者，你可以什么都不写，没有代码和需求自然没有腐烂的代码。

至于那些不为未来做假设的……我提醒你，你最好不要为自己的懒惰找借口。如果你不考虑未来如何重构更便利，那要么你会在每次重构时付出巨大代价，要么，你就会干脆放弃重构，代码自然就是“烂”掉的。

[hervey0424]

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

[shaozelin030405]

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

[kzfile]

不引入足够的额外能量，熵增是必然的。
不花很多力气去额外维护代码，腐败就是必然的

[cxsz]

本来有些地方是可以重构的，但是重构没有收益，还要承担发版的风险，所以最后就变成了，能跑就行

[jjx]

代码的优雅和 用户的需求是天生矛盾的


特别是业务端的, 100% n 年后就要重写

当然有人说 sap 这样的活了多少年, 其实你们没看到 isv 写了多少代码, 然后被废弃的

[DinnyXu]

我：好产品是需要打磨的
领导：不是时间短就做不出好产品

🥲

[cocong]

熵增定律，无处不在。

[fengpan567]

如果一个服务一直是一个人做那估计不会变 shit 山

[homewORK]

只要在一个模块上面开发的能力不同就会腐烂，这个能力主要受两个方面影响 开发人的技术 和 时间。 这两个很明显基本不可能具有同等效能

[egan0606]

根据需求变化，重构是一个相对来说，可以延缓代码持续时间的，可行性最高的方法，但是，屎山依旧是一定的；

[EndlessMemory]

我以前以为是技术不强导致的，现在看来是人性+制度+环境所造成的不可避免的必然结果

[tianzhiya]

“既然需求肯定会变，那么找到一种能适配需求多变，并且不会破坏已有代码的方法就好了，一种始终具有稳定性的方法。”这样可能就导致过度设计了。

[MoozLee]

这个需求临时加一下，今天就发版。
这个是老板要加的，不要管有没有用。
这个功能是给别的部门开发的，按他们的要求来做。