以前只是人云亦云地附和“技术债”，没细想，最近发现“需求变更”才是根源。
例如，领导说我们养个动物吧，比如仓鼠，然后你搭了一个小窝，结果领导牵来一头大象，你要么把窝改得不伦不类，要么拆了重盖。
这种需求与架构的不匹配，就会把原本良好的架构拉扯得稀碎。
浅聊一点技术债是怎么产生的？它可能是需求变更中一点点积累的，也可能是突然离谱需求导致实在没法适配的。
开发者面临的困境是，只能设计出符合项目最初需求的合理架构，没办法预知未知需求，但“需求变更”既合情合理也是常态。比如领导可能有一天会把大象换成鲸鱼。
所以，代码是注定会腐败的吗？
按常规思维来说是的，因为需求会一直变。但这也刚好暗示了应对方法：既然需求肯定会变，那么找到一种能适配需求多变，并且不会破坏已有代码的方法就好了，一种始终具有稳定性的方法。
 |
1
GuangXiN 10 天前
你找不到这种方法
|
 |
2
qs 10 天前 via iPhone  21
一切根源在于领导的"这个功能明天一定要上"
|
 |
3
Configuration 10 天前
要想不烂，就必须定期花时间重构，但是重构这件事在管理者看来是没有收益的，所以大部分人选择不做，“暂时能用就好，烂的时候说不定我都走了”
|
 |
4
iugo 10 天前
不单是需求变, 技术也在变. 依赖在变, 语言也在变.
代码也应该跟着变化. |
 |
5
julyclyde 10 天前
设计缺乏
重构缺乏 每天只是疲于奔命 |
 |
6
snitfk 10 天前
交付速度和技术债这两者是不可能两角。只能选其一。
|
 |
7
qiumaoyuan 10 天前 via Android
|
 |
8
CaffreySun 10 天前 2
最近在深入学习技术债的知识，有一本书特别好《管好技术债 低摩擦软件开发之道》，中文翻译的不是很好，有能力建议阅读英文书。
本质上软件系统是与其所在环境强绑定的，当环境发生变化时(如需求变化)就需要对系统进行调整，如果不及时调整就会与环境不适配，也就是你所说的“腐败”。 |
|
9
qiumaoyuan 10 天前 via Android 2
至于楼主说的“变化”，我认为其实也早有答案：不为未来设计的代码最简单，最简单意味着容易应对变化。而为未来设计的代码，往往会预测错未来。而真正的未来到到来的时候，不符合当下真实需求的、以前的一切预先设计都会化作阻力。
不过真能做到这一点的前提还是得有能力写出干净的代码，掌握上面链接里提到的能力，让代码全面贴合当下的需求，没有半点预先设计，也没有半点结构上的混乱。 |
|
10
qiumaoyuan 10 天前 1
|
 |
11
sagnitude 10 天前
有啊，从老板的角度看的话，每次变更都不计一切代价的让团队重构项目，雇一个团队干这事，也是一种解决方法
但作为维护系统的人，no silver bullet |
 |
12
xjzshttps 10 天前
就是需求变更
一个项目其中一部分代码全程是我自己实现的，持续多年后一样一塌糊涂。 原因就是需求变更。 每次增加新需求都要修改代码，然后老功能还不进行移除，有时候一个逻辑根据多个配置能走多个互相交错的代码路径。 我这还算好，时间足够会同步实现测试。但是后期时间紧张时测试就开始跟不上了。 有的项目乱倒一定程度后，我强硬进行重构，把功能改成插件式的就好多了。 但是一些项目并没有那么好做，特别是为了性能不能封装，或者即时封装也要向上层暴露一定细节就很烦了。 |
 |
13
woniu7 10 天前
什么，代码被需求渗透了，屎山革命，和平重构了
|
 |
14
thedog 10 天前
没有银弹，堆人月就好
|
 |
15
suom 9 天前 1
优秀的程序员，就算憋不住没厕所要拉屎(需求急)，也会挖个坑(单独一块区域)，拉了坨也会稍微盖一下(尽量做隔离)，再立一块牌子(写重要注释)，免得别人或者自己掉屎坑里。
而有些程序员，每天上班下班不论在哪(管他什么需求)，随地大小便(只管自己方便)，马桶里马桶外地上墙上天花板所到之处都能拉(需求做到哪里垃圾代码写到哪里)，别人问起来就是不关我事(模块不是我负责)、我没有拉(我只是该一点点不算动到)、别人也这样拉的(别说我垃圾代码内谁你怎么不说他)。 peace ～ |
 |
16
66450146 9 天前 via iPhone
需求变更来自于世界在变，发布的东西越多就会发现越多对这个世界错误的假设。代码的腐败是熵增的过程，软件系统也需要一直进化，尽量和这个组织对世界（主要是对付费用户）的了解才能保持速度
|
 |
17
pingdog 9 天前 via Android
写代码的人本意是好的，是代码执行时出了差错🌚
|
 |
18
momo2789 9 天前
熵增是不可逆的，所以定期重构是必须的，降低复杂度。
|
 |
19
buruoyanyang 9 天前
任何项目，只能想办法减缓变成屎山的速度，并不能杜绝他成为屎山。而且重构这个事情，对中上层，特别是整个公司不是由技术人说话的时候，是毫无意义的。
|
 |
20
paradoxs 9 天前
@qs 一切根源在于领导的"这个功能明天一定要上"
---------------------- 单纯的讨论这句话，是不负责任的。 因为你们没出钱，没感受到压力。 等哪天程序员自己出钱组建公司，一定比领导更狠。说不定就变成了：我今天就要上，干不完不许走。 |
|
21
qs 9 天前
@paradoxs
1. 我认为在这里讨论这些的确是不需要负责任的 2. `等哪天程序员自己出钱组建公司，一定比领导更狠` 领导和程序员的角色不冲突, 重点在于自上而下的决策压力. 一般情况下, 程序员(执行者)是面临来自产品经理(规划者)的压力, 产品经理面临来自上级老板的压力(决策层) 至于最上层是因为 资金压力、业务压力、外行领导内行还是资本家最朴素的心思, 确实不该是"程序员/下层员工"该考虑的事 而你表述的所谓这种"一定比领导更狠", 更印证了这种会导致重构无法成立往往来自于最上层的压榨 |
 |
22
kaneg 9 天前
"预知需求” 是需要的，但就和天气预报一样预报越久偏差会越大，而且成本也越高，老板耗不起让你做一个能满足百年一遇需求的方案来。
所以一切都是取舍，尽可能在通用和特殊之间达成一个平衡。 但随着时间和人员的变迁，如果没有持续的注入新的活力，大多数产品终会有掌控不住慢慢腐化的时候。 |
 |
23
metalvest 9 天前 via Android
linux 怎么就没腐烂呢
|
 |
24
strobber16 9 天前 via Android
先生，您这样是要加钱的
|
 |
25
vultr 9 天前
除了“这个功能明天一定要上”，还有一个应该也是很重要的，“只要能跑就行”。
|
 |
27
iseki 9 天前 via Android
有两个办法让代码不腐烂：每新增一个需求，就把代码重构为符合新需求+旧需求的样子。或者，你可以什么都不写，没有代码和需求自然没有腐烂的代码。
至于那些不为未来做假设的……我提醒你，你最好不要为自己的懒惰找借口。如果你不考虑未来如何重构更便利，那要么你会在每次重构时付出巨大代价，要么，你就会干脆放弃重构，代码自然就是“烂”掉的。 |
 |
28
hervey0424 9 天前
因为写的好不多给工资, 写的不好到时候也不用你改
|
 |
29
shaozelin030405 9 天前
需求变更可以接受。每次做完之后再做对应重构和总结，可以尽量减缓和避免这种情况。但是看是否给你时间了
|
 |
30
kzfile 9 天前
不引入足够的额外能量，熵增是必然的。
不花很多力气去额外维护代码，腐败就是必然的 |
 |
31
cxsz 9 天前
本来有些地方是可以重构的，但是重构没有收益，还要承担发版的风险，所以最后就变成了，能跑就行
|
 |
32
jjx 9 天前
代码的优雅和 用户的需求是天生矛盾的
特别是业务端的, 100% n 年后就要重写 当然有人说 sap 这样的活了多少年, 其实你们没看到 isv 写了多少代码, 然后被废弃的 |
 |
33
DinnyXu 9 天前
我：好产品是需要打磨的
领导：不是时间短就做不出好产品 🥲 |
 |
34
cocong 9 天前
熵增定律，无处不在。
|
 |
35
fengpan567 9 天前
如果一个服务一直是一个人做那估计不会变 shit 山
|
 |
36
homewORK 9 天前
只要在一个模块上面开发的能力不同就会腐烂，这个能力主要受两个方面影响 开发人的技术 和 时间。 这两个很明显基本不可能具有同等效能
|
 |
37
egan0606 9 天前
根据需求变化，重构是一个相对来说，可以延缓代码持续时间的，可行性最高的方法，但是，屎山依旧是一定的；
|
 |
38
EndlessMemory 9 天前
我以前以为是技术不强导致的，现在看来是人性+制度+环境所造成的不可避免的必然结果
|
 |
39
tianzhiya 9 天前
“既然需求肯定会变，那么找到一种能适配需求多变，并且不会破坏已有代码的方法就好了，一种始终具有稳定性的方法。”这样可能就导致过度设计了。
|
 |
40
MoozLee 9 天前
这个需求临时加一下，今天就发版。
这个是老板要加的，不要管有没有用。 这个功能是给别的部门开发的，按他们的要求来做。 |
 |
41
IndexOutOfBounds 9 天前 via Android
即使没有变化的需求，很多人也没有写出干净代码的意愿，更没有这个能力
|
 |
42
ZYXDemo 8 天前
抛掉各种客观因素，程序员一次心情不好不想正经搞，就会埋下灾难的种子
|
Select Language