请教有开发经验的高手

kelvingu616 2010-10-20 12:26:19

我们现在的项目的软件经过几个项目的开发，不断在原项目框架上通过打补丁添加新功能，使得结构很复杂，耦合度很高。
考虑过重构，但由于没有完整的需求和设计文档留下来，更没有测试文档和用例，使得我们不知如何下手。请教高手有什么办法呢？

...全文

136 点赞收藏 26

写回复

26 条回复

切换为时间正序

当前发帖距今超过3年，不再开放新的回复

发表回复

kelvingu616 2011-01-10

[Quote=引用 7 楼 sp1234 的回复:]

引用 5 楼 kelvingu616 的回复:
引用 4 楼 worcy_kiddy 的回复:

你们软件本身架构就是不好，而且做得比较混乱，只能做下次项目时注意这些事情，你们开发人员可以把自己负责的模块重构一下！但是至少项目的相关文档需要补全吧？这些都没有，也太。。。。。。

同意您的观点，把文档补全无论对现在项目还是以后的开发都有好处

这是片面的。只有当项目基本上一年……
[/Quote]
对，我们现在就是慢慢写测试来进行。
文档的事情，可以说不够敏捷，也可以说是因为我们太懒了，就先不写了=0=

回复赞

eagleatustb 2011-01-04

[Quote=引用 7 楼 sp1234 的回复:]
引用 5 楼 kelvingu616 的回复:
引用 4 楼 worcy_kiddy 的回复:

你们软件本身架构就是不好，而且做得比较混乱，只能做下次项目时注意这些事情，你们开发人员可以把自己负责的模块重构一下！但是至少项目的相关文档需要补全吧？这些都没有，也太。。。。。。

同意您的观点，把文档补全无论对现在项目还是以后的开发都有好处

这是片面的。只有当项目基本上一年不……
[/Quote]
我也碰到这样的问题，原来的程序很乱，改了这个发现另个一个又不行了，改了几次就不敢改了，现在准备做到自动化出来以后才真正着手重构。建议楼主参考这个！

回复赞

ZSY2012 2010-12-30

由于没有相关需求和设计文档，要想重构大概要多劳神费力些了。我以前也碰到过这样没有文档、又很错综复杂的项目。那时是这样做的，第一步，当然要理解原来的程序，以大的结构方面为主，理清其关系（特别是控制关系等）。第二步，梳理其总的结构及其控制关系，与子系统结合紧密的尽量解耦到各个子系统中。第三步，逐步吃掉各个子系统，理清它们内部以及在此基础上它们之间的关系（或裁或增，或拆或合，或升或降等）。在整个处理过程中，为稳妥起见，原来的内容保留以备参考，但与新的内容并举，即重新构建一段路，在碰到问题时可以随即切换到原来的部分看看二者的异同以便找出新内容的问题；在新的部分运行稳定后可以干净地去掉原来的。不知于你有没有用，编程快乐。

回复赞

cnyining 2010-12-28

我觉得代码也是文档。
一般可以这样干：
先搞明白业务，再把代码的结构关系理清楚，加入一些必要的注释；
最后，根据代码、业务等，决定如何重构；重构包括代码级的、系统级的。

回复赞

纪争光 2010-12-07

我也在看代码，很少注释的代码。

的确要是逻辑复杂了，肯定乱七八糟的，扯东扯西

回复赞

cwzmb 2010-12-07

[Quote=引用 19 楼 worcy_kiddy 的回复:]

引用 14 楼 cwzmb 的回复:
我以前有过类似的经验不知道适不适合你。
当初我们做了个视频传输client,不是我做的。
因为该Client在广域网上传输有马赛克，估计是丢帧导致，客户急需解决这BUG。
但做该Client的那个程序员已经辞职，他的代码也写的很乱，我们已经投入几个人员想尝试去看懂他的代码，还是无所获！因为实在看不懂，花了1个月也解决不了问题。
最后我提出一个方案，……
[/Quote]
抱歉我写的有点模糊，这一个月包括看他的程序，然后猜测在哪个地方出错，然后修改，没解决问题，又继续看他的代码，如此循环！花了一个多月没把BUG解了。而且，其实他的代码还是没有完全看懂。

回复赞

纪争光 2010-12-05

[Quote=引用 14 楼 cwzmb 的回复:]
我以前有过类似的经验不知道适不适合你。
当初我们做了个视频传输client,不是我做的。
因为该Client在广域网上传输有马赛克，估计是丢帧导致，客户急需解决这BUG。
但做该Client的那个程序员已经辞职，他的代码也写的很乱，我们已经投入几个人员想尝试去看懂他的代码，还是无所获！因为实在看不懂，花了1个月也解决不了问题。
最后我提出一个方案，终于在两个星期内解掉该BUG。
那就是重……
[/Quote]

替换关键模块。
倒也可行。能复用的复用

回复赞

黑泡泡选手 2010-12-04

[Quote=引用 14 楼 cwzmb 的回复:]
我以前有过类似的经验不知道适不适合你。
当初我们做了个视频传输client,不是我做的。
因为该Client在广域网上传输有马赛克，估计是丢帧导致，客户急需解决这BUG。
但做该Client的那个程序员已经辞职，他的代码也写的很乱，我们已经投入几个人员想尝试去看懂他的代码，还是无所获！因为实在看不懂，花了1个月也解决不了问题。
最后我提出一个方案，终于在两个星期内解掉该BUG。
那就是重……
[/Quote]

看了一个月都没看懂？那家伙写得什么程序？那惨了！

回复赞

showerXP 2010-12-04

基本不能改。
能不能改，很大程度上看你设计时候抽象的结果。

回复赞

yuxh81 2010-12-01

[Quote=引用 14 楼 cwzmb 的回复:]

我以前有过类似的经验不知道适不适合你。
当初我们做了个视频传输client,不是我做的。
因为该Client在广域网上传输有马赛克，估计是丢帧导致，客户急需解决这BUG。
但做该Client的那个程序员已经辞职，他的代码也写的很乱，我们已经投入几个人员想尝试去看懂他的代码，还是无所获！因为实在看不懂，花了1个月也解决不了问题。
最后我提出一个方案，终于在两个星期内解掉该BUG。
那就是……
[/Quote]

UP

回复赞

Pro_X 2010-12-01

如果软件系统的模块数量超过一定程度,几乎无解.

回复赞

archonwang111 2010-12-01

重构吧。这个工作比较吃力点。

回复赞

cwzmb 2010-11-29

我以前有过类似的经验不知道适不适合你。
当初我们做了个视频传输client,不是我做的。
因为该Client在广域网上传输有马赛克，估计是丢帧导致，客户急需解决这BUG。
但做该Client的那个程序员已经辞职，他的代码也写的很乱，我们已经投入几个人员想尝试去看懂他的代码，还是无所获！因为实在看不懂，花了1个月也解决不了问题。
最后我提出一个方案，终于在两个星期内解掉该BUG。
那就是重新编写一个视频传输的模块，做成DLL，然后把原有程序的相关代码替换成调用该DLL。

所以，我认为你是否可以也这样做，对实在很乱没法看得懂的模块重新实现，替代掉原先的；
对不乱的稍微有点不合理的模块，进行修改；对已经很好的模块，保留！
每修改或重新实现一个模块，要对应产生相应的概要文档，没必要写那么详细。

回复赞

jiaorg 2010-11-03

第一步，现在开始写文档
第二部、可以逐个逐个模块的重构吧，

回复赞

kelvingu616 2010-11-03

现在我们是想进行自动化测试。
但测试是要基于设计文档，才能清楚函数、模块的意图。
现在苦于没有这些文档，测试很能进行。

回复赞

纪争光 2010-10-31

[Quote=引用 10 楼 worcy_kiddy 的回复:]

引用 7 楼 sp1234 的回复:
引用 5 楼 kelvingu616 的回复:
引用 4 楼 worcy_kiddy 的回复:

你们软件本身架构就是不好，而且做得比较混乱，只能做下次项目时注意这些事情，你们开发人员可以把自己负责的模块重构一下！但是至少项目的相关文档需要补全吧？这些都没有，也太。。。。。。

同意您的观点，把文档补全无论对现在项目还是以后的开发都有好处
……
[/Quote]

哎，这样讨论都只是建立在如果的基础上。

额。推倒重来不行，重做的话又要纠结于很多东西，难以抉择呀。

回复赞

加油馒头 2010-10-28

后面增加开发时，尽量多注意些，从耦合度，关联度方面

回复赞

黑泡泡选手 2010-10-28

[Quote=引用 7 楼 sp1234 的回复:]
引用 5 楼 kelvingu616 的回复:
引用 4 楼 worcy_kiddy 的回复:

你们软件本身架构就是不好，而且做得比较混乱，只能做下次项目时注意这些事情，你们开发人员可以把自己负责的模块重构一下！但是至少项目的相关文档需要补全吧？这些都没有，也太。。。。。。

同意您的观点，把文档补全无论对现在项目还是以后的开发都有好处

这是片面的。只有当项目基本上一年不……
[/Quote]

嗯，你说得很对，敏捷开发（迭代）使用自动化测试非常得有用，但是有没有意识做，有没有能力做，还是一个问号！

回复赞

以专业开发人员为伍 2010-10-28

如果不懂自动测试，那么维护一堆这样生成的代码之后还要补充更多垃圾文档，就注定完蛋了。

回复赞

以专业开发人员为伍 2010-10-28

[Quote=引用 5 楼 kelvingu616 的回复:]
引用 4 楼 worcy_kiddy 的回复:

你们软件本身架构就是不好，而且做得比较混乱，只能做下次项目时注意这些事情，你们开发人员可以把自己负责的模块重构一下！但是至少项目的相关文档需要补全吧？这些都没有，也太。。。。。。

同意您的观点，把文档补全无论对现在项目还是以后的开发都有好处
[/Quote]

这是片面的。只有当项目基本上一年不改动时才有必要慢慢纠结文档。而如果要求比较敏捷，则应该补充几百个自动化测试，这样在任何变化和增加测试时都会因为必须严格的自动测试强度而发现架构（这样才敢于重构），而不是空洞的文档。

回复赞

加载更多回复