中午休息,邀请各位过来讨论下代码的修改问题

[rickmeteor]

最近做的项目中,按照客户的需求分析写完了一本详细设计.
最后客户需求变化了,直接去掉了复杂的审核机制,导致这本详细设计做的出来的代码基本失效.
因为时间原因,我没自己操刀去修改.
另一个程序员完成修改后,一直抱怨我代码写的烂.修改我的代码实现客户的功能麻烦得要死.
建议我事先考虑好客户的动作,不要把代码的约束写那么死.

本人功底不深,想了解下.
软件工程里的高内聚,低耦合的思想.能不能用在我这里?
我日后是否应该继续追求代码的重构,按业务归纳私有方法.
大家有什么好的建议.欢迎拍砖.^_^

[wangyin2001]

没有一沉不变的东西，“改”是太正常的情况了。关于代码结构，个人感觉要看项目大小，也可以说是看项目的总额和利润了。比如微软和sun的各个开发平台，很难说到底谁好谁坏。

[wzju64676266]

代码的风格按照公司规定了就行了，你如果要搞独立的话就一不行，你平时写的代码如果都很正规的话，一般别人也不会说什么

[believefym]

[Quote=引用楼主 rickmeteor 的回复:]
最近做的项目中,按照客户的需求分析写完了一本详细设计.
最后客户需求变化了,直接去掉了复杂的审核机制,导致这本详细设计做的出来的代码基本失效.
因为时间原因,我没自己操刀去修改.
另一个程序员完成修改后,一直抱怨我代码写的烂.修改我的代码实现客户的功能麻烦得要死.
建议我事先考虑好客户的动作,不要把代码的约束写那么死.

本人功底不深,想了解下.
软件工程里的高内聚,低耦合的思想.能不能用在我这里?
我日后是否应该继续追求代码的重构,按业务归纳私有方法.
大家有什么好的建议.欢迎拍砖.^_^
[/Quote]

去掉一个审核机制就使代码基本失效，有点严重了，
可能是你没把功能抽象好，

api_1(para) -> api_2(para) - ...

很明显你如果把api_1, api_2....都整在一起，一旦需要拿掉某一个接口功能时，就像你说的去掉审核机制， 代码很有可能就废了。

楼上多数提到了风格问题，那是小问题，大问题是设计

[长公子冰]

[Quote=引用 1 楼 jinxfei 的回复:]
别人说你的代码烂，未必真烂，说不定是他的思路更烂。

当然，以上只是猜测。

在现实生活中，基本上大家都会觉得别人写的代码差劲。
[/Quote]

前辈这话说的太对了，我维护别人的代码时觉得很吃力，恨不得自己重写。

可能是每个人的思维方式不同吧！不过有人的代码写的确实不怎么样，而有人还是水平很高的!思维严谨，代码流畅而最受规范，用简洁的代码完成功能的实现。有个哥们些了一个方法竟然用了1千多行的代码自己竟然没晕我维护他的代码时已经找不到北了。我最讨厌一个方法写那么长了，我宁愿拆开几个方法来写，起码思路清晰一些。而且维护起来也容易，要不然写那么长的代码，稍微一改不知道会不会改错。

[临碣]

说我代码烂,你要先看懂才行.

哈哈

反正经常看得别人一头雾水

[jinxfei]

别人说你的代码烂，未必真烂，说不定是他的思路更烂。

当然，以上只是猜测。

在现实生活中，基本上大家都会觉得别人写的代码差劲。

[pupppet]

代码这东西，不要写完了就扔一边不管了，多看看想想还有哪些地方可以优化。。。如此这般多做几次。。。会有收获的。。。

[wangyin2001]

不懂得欣赏别人的人，好不到哪去。。不用太介意。