这是一个创建于 1430 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司一个将近 20 年的 mfc 项目，体积庞大，没人能全懂。公司要求每次修改都要注释作者 /时间 /修改内容，由于人员水平参差不齐，导致注释完备但代码难懂。部分文件几经变迁，混杂着各种业务代码与黑魔法，例如几十行的逻辑判断，旁边有各年代留下的为什么加这个判断的注释。 请问有什么方案可以管理代码的变更，优雅的反应代码如何到今天这样子，而只需对代码做最少的更改？
 |
1
kiracyan 2021-01-25 10:33:58 +08:00
别动
|
 |
2
caijihui11 2021-01-25 10:35:24 +08:00
别动
|
 |
3
kaiki 2021-01-25 10:36:03 +08:00
不要管理，新功能就用新代码，出 BUG 找不到负责人就把这部分重新写一个。
|
 |
4
kop1989 2021-01-25 10:38:16 +08:00
这个很难。
1 、注释有可能不正确，也有可能过期。 2 、代码中的逻辑未见得都有效。 你很难通过简单规则来把代码变更的历史追溯起来了。 所以你需要做的是确保当前版本可用。然后引入版本管理软件。 |
 |
5
BeautifulSoap 2021-01-25 10:40:53 +08:00  1
「不要乱动！不要乱动！！不要乱动！！！」
|
 |
6
ltm 2021-01-25 10:41:24 +08:00 1
公司认可：用 C#重写一个；
否则，别动，继续加屎，知道大厦崩塌 我也曾经在屎山上实践过《重构》的，但是，真的不如推倒重来 |
 |
7
nicevar 2021-01-25 10:42:53 +08:00
不要乱动，这是真理，特别是线上跑了很多年的项目
总有些人有代码洁癖又盲目自信，结果弄出大故障的 |
 |
8
murmur 2021-01-25 10:45:09 +08:00
除非出现了导致系统不能运行的 bug，千万不要动
|
 |
9
bfdh 2021-01-25 10:48:20 +08:00
交给下一任管理者？
|
 |
10
Aaronsunny 2021-01-25 10:51:09 +08:00
不要乱动
|
 |
11
fixend 2021-01-25 11:02:40 +08:00 1
1 、大部分人的选择都是别乱动，新功能用新代码，
然后，后面会陆续出现，同样 /类似功能的函数会有 N 个， 甚至同样意义的常量也有 N 个，有一大堆无用或不明意义的代码， 总的来说，代码会退化得越来越严重。 2 、从公司的角度来看是不好的发展，从程序的角度来看：关我鸟事，我能完成上面安排的需求就得了。 3 、最好是进行大规模重构、重写，但多数公司都不会支持，风险也很大，新版本不一定就做得比旧的好。 |
 |
12
40EaE5uJO3Xt1VVa 2021-01-25 13:39:32 +08:00
投个硬币，正面重构，反面不动。没有硬币投个手机也行
|
 |
13
MaverickLee 2021-01-25 13:43:43 +08:00 1
继续往上拉屎
|
 |
14
wolfan 2021-01-25 14:02:56 +08:00 via Android
当没见过，只要你没见过，那就不存在！
|
 |
15
zsc8917zsc 2021-01-25 14:08:54 +08:00 2
参考一下 oracle 的维护。
不要相信注释，要相信自己的调试。 如果想重构，那就先维护好测试用例。 |
 |
16
wmhx 2021-01-25 14:13:04 +08:00
20 年累计的注释, 代码逻辑早就不是那么回事了, 还是等钱到位了刚一波吧.
|
 |
17
NexTooo 2021-01-25 14:24:19 +08:00
别动。你不会知道这一句看着毫无意义且让人难受的垃圾代码，是为了哪个问题而存在的。。
|
 |
18
firefox12 2021-01-25 14:25:22 +08:00
如果有能力 把 20 年的屎山理得干干净净 清清楚楚 你就去做， 考虑下， 所有的 业务需求是否清楚，所有用例是否完备， 所有的依赖是否到位， 你要花多少时间？
|
 |
19
AndyAO 2021-01-25 14:27:18 +08:00
如果你要做很大的改动，那么最好的方法是不要动而选择重新写，因为动的成本比重新写可能要高很多.
这个临界点好像是在 10%~20%左右，这是在软件工程的书上写着的. 当然这不意味着完全抛弃之前的东西，里面有很多的设计的理念是可以通用的，是可以迁移的，这些东西要学会. 如果你已经决定进行比较少的改动，那么在要逐步的建立起相关的测试和文档，如果有这些东西，那么就会容易很多. |
|
20
AndyAO 2021-01-25 14:33:08 +08:00
@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. |
 |
21
xuanbg 2021-01-25 16:07:45 +08:00
萧规曹随即可……这种场景就别多事了。
|
 |
22
Flymachine 2021-01-25 16:56:52 +08:00
别动，重新写。有的时候，甚至编译环境的不同都可能引发 BUG 。最好的方案就是重新写——换 QT 或者干脆 C#。
|
 |
23
boris93 2021-01-25 17:14:31 +08:00 via Android
继续拉屎就好了
直到公司决定重写 |
 |
24
leafre 2021-01-25 17:47:03 +08:00
老代码能不动就不动
|
 |
25
gengzi 2021-01-25 17:57:03 +08:00
别动
|
 |
26
shatuo 2021-01-25 18:13:36 +08:00
@yanzhiling2001 这是换手机的好方法
|
 |
27
huobazi 2021-01-25 18:56:39 +08:00
想把 摩托罗拉 汉显 重构成 iPhone 12 ？
|
 |
28
littiefish 2021-01-25 22:39:53 +08:00 via iPhone
终于明白了为啥 APP 越来越大
|
 |
29
fline 2021-01-25 22:40:34 +08:00
找 HR 要个实习生处理
|
 |
30
DoctorCat 2021-01-25 23:01:50 +08:00
不要动，加 Patch，FIXME 注释写下自己的修改思路即可（方便自己再次修改而已，doge ）
|
 |
31
dany813 2021-01-26 09:21:07 +08:00
看到老哥们都说别动，我就放心了
|
 |
32
kingfalse 2021-01-26 09:41:13 +08:00 via Android
同意楼上继续拉屎，啥时候不行了就会变成印度那个航母，因为屎而爆炸
|
 |
33
gaoyadianta 2021-01-26 09:56:08 +08:00
首先，并不一定历史悠久，几经易手，体积庞大，就一定是 shit 代码，可能是你对老的 coding 习惯不适应，也可能是你对业务理解不深入，反正不要盲目自信瞎改
|
Select Language