公司一个将近 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 习惯不适应,也可能是你对业务理解不深入,反正不要盲目自信瞎改
|