最近一直在改写之前老项目的垃圾代码，五年前十年前的代码设计模式的变化感觉如何吗？

[MuscleOf2016]

为什么有人可以堂而皇之的写出如此难维护的代码？？

[janxin]

我们只是临时实现一个功能-》哎呀这功能反馈不错，我们完善一下-》哎呀怎么这么复杂，我们还是打打补丁吧-》卧槽！祖传屎山！

[MuscleOf2016]

@cstj0505 另外 有什么网站公开一下久远的代码的？

[smeraldo]

反正 gang of four 是二十几年前的东西了🙃
code smell 也是上世纪 90s 开始流行的概念

[index90]

@cstj0505 拿 glibc 和 postgresql 来比有点欠妥，这些都是基础软件。现在大部分国内开发者都是互联网开发者。
过去的是软件产品，现在是产品软件。过去能开发软件的没有几家公司，软件就摆在那，用户自己来用，是用户适应软件。而现在是把软件包装成产品，送到用户面前，软件去适应用户。
前者可以按照瀑布模式或者小瀑布模式开来发，软件在编写之前就已经设计好了，过程不接受变更，自然容易写出规范的代码。而后者则需要快速响应用户的需求变化，快速开发（不能说是快速迭代），快速发布是关键。
产品如果活不下来，你代码再优美，也只剩下程序员自嗨罢了。

[iamsheep]

破窗效应，可维护性又不会计入绩效，又没有 code review，加班都是在写新需求（新 bug ），代码转个几手就根本没眼看了，这种事要预防根本不能依赖个人自觉，还是要优化流程。

[wee911]

@zwh2698 就因为是搞工程才要考虑代码写的好不好， 以后好维护，搞工程就是这样， 搞学术的反而是无所谓代码写的好不好，他们更关注实现算法

[Banxiaozhuan]

其实不是代码垃圾，而是维护这个代码的人一波又一波的换。
新上的人在没有完全熟悉这款业务的时候又不敢随便改，等熟悉了以后，又想着跳槽，或者偷懒。
除非遇到一个极其负责的人维护，但是这种人很少。
所以不要喷以前的老代码写的很差，如果差，请你把他改好。

[zhenizhui]

我估计需求都没搞清楚

[gamexg]

有些是菜，有些是懒，还有一些是需求的变更逼得代码结构越来越烂。

[dorentus]

十年前不就是才 2009 年吗，Stack Overflow 和 Github 都有了……

[inrenping]

能稳定运行十年的代码还是有可取之处的，不要只看缺点。

[mingl0280]

五年十年这个时间有点短了，我司 99-05 年的代码到现在都还是很易于维护的，规范的代码很重要……

[cstj0505]

@MuscleOf2016 搜一下吧，很容易找到的，包括 linux 内核的。pg 的代码在官网能找到

[sugars]

有些人为了实现功能而写代码，都不往长远地考虑

[k9990009]

开发时需求不明确，开发后需求变更，时间又逼着紧，当然代码堆砌来的快咯。给时间啥都好说

[x86]

你敢保证你写的东西 5 年，10 年后还在被使用吗

[passerbytiny]

设计模式可以十年不变，但成品代码 3 年不变就没前途，5 年不变就可以扔垃圾箱了。一个 5 年不变的代码，如果能用，那绝对是过度超前设计，开发成本要数倍于垃圾代码推到重做。

[jrtzxh020]

能稳定运行这么多年，代码已经很好了吧。。。

[MuscleOf2016]

@jrtzxh020 我哭了，append 已经解释了，不是说我遇到五年十年前的代码，是讨论下五年十年前的设计模式

[gulili]

@passerbytiny 说的很有道理。我们有个项目就是从十多年前继承下来的代码，到现在已经到了没办法维护的地步了，不得不整体重构。在我看来，如果是设计模式问题，很可能是因为产品定位和需求变更，这么多年，可能产品经理，架构，开发都换了几波了，公司的业务结构重心也变化很多。之前设计的人不可能预见到 10 年后的需求是怎么样的。并且像很多大佬说的，作为工程师，设计的架构主要是满足需求，over-design 一样会给项目带来不好的结果。