如何管理历史悠久，几经易手的代码？

• 資深大佬 : kiracyan

  别动

• 資深大佬 : caijihui11

  别动

• 資深大佬 : kaiki

  不要管理，新功能就用新代码，出 BUG 找不到负责人就把这部分重新写一个。

• 資深大佬 : kop1989

  这个很难。
  1 、注释有可能不正确，也有可能过期。
  2 、代码中的逻辑未见得都有效。

  你很难通过简单规则来把代码变更的历史追溯起来了。
  所以你需要做的是确保当前版本可用。然后引入版本管理软件。

• 資深大佬 : BeautifulSoap

  「不要乱动！不要乱动！！不要乱动！！！」

• 資深大佬 : ltm

  公司认可：用 C#重写一个；

  否则，别动，继续加屎，知道大厦崩塌

  我也曾经在屎山上实践过《重构》的，但是，真的不如推倒重来

• 資深大佬 : nicevar

  不要乱动，这是真理，特别是线上跑了很多年的项目
  总有些人有代码洁癖又盲目自信，结果弄出大故障的

• 資深大佬 : murmur

  除非出现了导致系统不能运行的 bug，千万不要动

• 資深大佬 : bfdh

  交给下一任管理者？

• 資深大佬 : Aaronsunny

  不要乱动

• 資深大佬 : fixend

  1 、大部分人的选择都是别乱动，新功能用新代码，
  然后，后面会陆续出现，同样 /类似功能的函数会有 N 个，
  甚至同样意义的常量也有 N 个，有一大堆无用或不明意义的代码，
  总的来说，代码会退化得越来越严重。

  2 、从公司的角度来看是不好的发展，从程序的角度来看：关我鸟事，我能完成上面安排的需求就得了。

  3 、最好是进行大规模重构、重写，但多数公司都不会支持，风险也很大，新版本不一定就做得比旧的好。

• 資深大佬 : yanzhiling2001

  投个硬币，正面重构，反面不动。没有硬币投个手机也行

• 資深大佬 : MaverickLee

  继续往上拉屎

• 資深大佬 : wolfan

  当没见过，只要你没见过，那就不存在！

• 資深大佬 : zsc8917zsc

  参考一下 oracle 的维护。
  不要相信注释，要相信自己的调试。
  如果想重构，那就先维护好测试用例。

• 資深大佬 : wmhx

  20 年累计的注释, 代码逻辑早就不是那么回事了, 还是等钱到位了刚一波吧.

• 資深大佬 : NexTooo

  别动。你不会知道这一句看着毫无意义且让人难受的垃圾代码，是为了哪个问题而存在的。。

• 資深大佬 : firefox12

  如果有能力 把 20 年的屎山理得干干净净 清清楚楚 你就去做， 考虑下， 所有的 业务需求是否清楚，所有用例是否完备， 所有的依赖是否到位， 你要花多少时间？

• 資深大佬 : AndyAO

  如果你要做很大的改动，那么最好的方法是不要动而选择重新写，因为动的成本比重新写可能要高很多.

  这个临界点好像是在 10%~20%左右，这是在软件工程的书上写着的.

  当然这不意味着完全抛弃之前的东西，里面有很多的设计的理念是可以通用的，是可以迁移的，这些东西要学会.

  如果你已经决定进行比较少的改动，那么在要逐步的建立起相关的测试和文档，如果有这些东西，那么就会容易很多.

• 資深大佬 : AndyAO

  @AndyAO #18
  回去查证了一下，发现记忆有些偏差，这里补充相关资料

  **关于修改和重写的临界点问题**

  有关软件错误和软件成本的研究都证实了这一基本事实。本书中反复提到了 NASA-Goddard 所属的 SEL 。SEL 曾详细比较了修改旧代码和完全重写所需的成本问题（ McGarry 等，1984 ； Thomas1997 ）。他们的结果清晰明确，给人深刻的印象。如果现有软件系统的 20%~25%以上需要修改，那么从头构建新产品更便宜、更容易。这个百分比低的惊人。[1]

  **关于遗留代码与单元测试**

  在业内人士的口中，“遗留代码” 一词常常是”无法理解的、难以修改的代码”的代名词。然而，在多年来与形形色色的开发团队共事，并帮助他们解决重大的编码问题的过程中，我总结出了一个不同的定义。对我来说，遗留代码就是那些没有编写相应测试的代码。明白这一点是很痛苦的。人们会问，代码的好坏与是否编写了测试有什么关系呢？答案很明显，而这也正是我将要在本书中阐述的：没有编写测试的代码是糟糕的代码。不管我们有多细心地去编写它们，不管它们有多漂亮、面向对象或封装良好，只要没有编写测试，我们实际上就不知道修改后的代码是变得更好了还是更糟了.反之，有了测试，我们就能够迅速、可验证地修改代码的行为 …

  开发团队的水平在不断提高，他们编写的代码也变得越来越清晰，然而旧代码要想变得更清晰就要花更长的时间。许多情况下旧代码甚至永远都不可能变得完全清晰。正因如此，我将“遗留代码”定义为“没有编写测试的代码”，而且它本身就提出了问题的一条解决方案。…[2]

  [1]〔美〕 RobertL.Glass. 软件工程的事实与谬误[M]. 中国电力出版社, 2006.
  [2] 修改代码的艺术 : Working effectively with legacy code[M]. 人民邮电出版社, 2007.

• 資深大佬 : xuanbg

  萧规曹随即可……这种场景就别多事了。

• 資深大佬 : Flymachine

  别动，重新写。有的时候，甚至编译环境的不同都可能引发 BUG 。最好的方案就是重新写——换 QT 或者干脆 C#。

• 資深大佬 : boris93

  继续拉屎就好了
  直到公司决定重写

• 資深大佬 : leafre

  老代码能不动就不动

• 資深大佬 : gengzi

  别动

• 資深大佬 : shatuo

  @yanzhiling2001 这是换手机的好方法

• 資深大佬 : huobazi

  想把 摩托罗拉 汉显 重构成 iPhone 12 ？

• 資深大佬 : littiefish

  终于明白了为啥 APP 越来越大

• 資深大佬 : fline

  找 HR 要个实习生处理

• 資深大佬 : DoctorCat

  不要动，加 Patch，FIXME 注释写下自己的修改思路即可（方便自己再次修改而已，doge ）

• 資深大佬 : dany813

  看到老哥们都说别动，我就放心了

• 資深大佬 : kingfalse

  同意上继续拉屎，啥时候不行了就会变成印度那个航母，因为屎而爆炸

• 資深大佬 : gaoyadianta

  首先，并不一定历史悠久，几经易手，体积庞大，就一定是 shit 代码，可能是你对老的 coding 习惯不适应，也可能是你对业务理解不深入，反正不要盲目自信瞎改