现在有点明白什么是技术债了

“让我从头写，我保证不会有屎山代码” 狗头～

重构（ doge

技术高利贷

@justdoit123 之前只搞过 CRUD ，没啥经验，这个感觉太吃经验了

@Cheons 我想着其他 title 比我高的人会看不下去然后重构呢，但是他们也只是默默地在屎山上耕耘

主要还是看对需求的预测，做少了欠债，做多了过度设计，没有最好，只有更好

放心，就 lz 这项目需求的变动频率和变动规模
就算一开始好好设计最终成品也不过是精致的屎山

所有的项目都是这样的
1.要么你有能力在开发的时候就把技术债务解决（成本最高）
2.要么你就是用最快的速度做出来（省钱省时间，当下成本最优解）
3.要么你就是过一段时间项目稳定阶段利用前期积累的经验做一次重构（中长期项目，最优解）

前一个阶段为什么流行中台，最核心的目的就是把老旧系统有价值的功能摘出来，重新组建一个系统找人重新维护开发，进行代码重构和文档补充，同时进行性能优化和架构升级。

没有技术债务的项目就像是在上帝视角看问题，能对需求方向有绝对的管控权利，不然的话是不可避免，只是有经验的人会减少技术债务，但绝对不会没有。

这个世界上没有绝对完美的东西 都是各种因素妥协的产物，软件工程亦是如此。能支撑好业务 就是好系统 重构优化这是底线，你的开发体验的优先级并不会很高。

就这一句 结果后边需求一值变 怎么搞都是债

@ZZ74 一开始是给了要支持好几个平台的暗示的，但没想到是这个月交付这个平台的，下个月交付另一个平台的，下个月再换一个，但是需求是正常推进的

八成本来也没钱没资源从头开始搞成精品...

放弃完美主义情结，人类发展了几百万年，还到处是纷争。
微软 windows 已经不惑 了，还在更新。

看看 yocto

我们之前也是类似，追快，产出了很多不可名状的功能代码，奇怪的拼接。

都一样的哪怕是牛逼的
Jetbrains 重做 ide 也是麻烦。

@zhuangzhuang1988 jb 他们修复 ide 输入中文问题修了十几年了 还没修好. 产品经理发誓都好几次了, 说了几次 这个版本绝对修好了.

没有经验的话，基本就是这样的啦。能在没有经验的前提下做好结构设计，为以后的扩展和局部重构建立基础的人万中无一。

局部最优解不一定是全局最优解。

最佳的设计实践就是在迭代的过程中重构。

技术债就是自己技术不行赖管理。

随着项目发展，总会有新需求，不可能一开始就想完整。
所以我觉得不断重构是长期项目的唯一解。不过这样仍然会遇到瓶颈，总会有局部重构也解决不了的问题，这时候就只能整体重来了。

我最近也是在重构之前一个项目，我的理解是，局部代码可以省，架构绝对不能凑合。
架构好后面都能修修补补，架构初期凑合，后面真是恐怖，每天都在屎山雕花。另一个项目就是初期架构好，现在都可以局部重构，至少每天都在变得更好

@nyxsonsleep 没有全局最优解 你没有 10000 次随机迭代的机会

技术债就是项目管理不行赖技术，哈哈

@blahblahblah 除了问题怕负责

@clemente #23 那就是管理能力的差异体现了。

我个人的理解就是:

1. 甲方爹且乙方软
2. 缺乏理论知识（架构方面

接触的用了 10 年的老旧系统，编码五花八门没个标准，应用性能极差，老板舍得花二十几堆硬件但就是不愿推进项目重构。重构就面临着风险和放权，不是技术型公司太难推进了。