1,265
社区成员
发帖
与我相关
我的任务
分享关于重构的一些想法，大家讨论 --=100分=-- 请ozzzzzz 爱忘记 等前辈来看看
不知道各位高人对于XP怎么看，这里我想跟大家讨论一下重构（Refactory)的看法。
在Kent的书上说按照XP的思想，不需要在前期进行大量的冗余的设计工作，设计是在不断的重构的过程中慢慢浮现出来的。但是在本人的实践中发现“重构”和“过度重构”（我发明的词，指发现问题就重构，也就是不计成本的、随意的重构，因为他和过度设计的起因类似，都是因为程序员的完美情节引起所以这么叫）之间很难进行界定。应该怎么控制呢？（具体用语可能不当，意思表达的不是很清楚，大家讨论吧）
另外，记得在论坛里见到过某位高人说过在他们的项目中对于代码中的坏气味有着严格的定义，一旦发现代码中有坏气味，就需要重构了，不知能否在这里将你们的坏气味的标准公布一下，大家一起进步啊！
最后，哪位高人有关于重构的工具（最好是cpp or c#）这里推荐一下，我想这些工具可以让我更加了解重构是什么！
谢谢
在Kent的书上说按照XP的思想，不需要在前期进行大量的冗余的设计工作，设计是在不断的重构的过程中慢慢浮现出来的。但是在本人的实践中发现“重构”和“过度重构”（我发明的词，指发现问题就重构，也就是不计成本的、随意的重构，因为他和过度设计的起因类似，都是因为程序员的完美情节引起所以这么叫）之间很难进行界定。应该怎么控制呢？（具体用语可能不当，意思表达的不是很清楚，大家讨论吧）
另外，记得在论坛里见到过某位高人说过在他们的项目中对于代码中的坏气味有着严格的定义，一旦发现代码中有坏气味，就需要重构了，不知能否在这里将你们的坏气味的标准公布一下，大家一起进步啊！
最后，哪位高人有关于重构的工具（最好是cpp or c#）这里推荐一下，我想这些工具可以让我更加了解重构是什么！
谢谢
...全文
请发表友善的回复…
发表回复
twinsant124 2002-12-24
- 打赏
- 举报
and why i can NOT read SHIRUMARU's post in Janpanese OS?
twinsant124 2002-12-24
- 打赏
- 举报
Pasted error......:(
twinsant124 2002-12-24
- 打赏
- 举报
1.今天看完了MMM的是与非那章,闭上眼想了好一阵,有些东西让我再多想想,再和大家讨论吧.
2.从上周又翻出了XP Install来找一些理论,还捎带复习一些编译方面的理论.
3.最近在努力阅读着ROC++,练习着FengYuan的那本WindowsGDI的宝典的例子,还要看完WEUC,并努力完成着我们的那个项目.
所以,很忙.不过,既然有同志要谈高,我就插下嘴,给大家揭示有这么一种态度:
a.我从每期必买的程序员上(不过,12期的不想买,不知道以后的能不能再勾起我的兴趣)早就拜读了高的文章.很早的时候,我看不懂;过了一阵,从大三下学期发奋地看软件工程的东西,可以渐渐理解了某些文章的只言片语,不过,大部分还是没有实践经验对照,还是不懂,俺就想,是不是水平不够呢,我要努力;但,从高对UML的攻击到发明了所谓的2G的OO(还好,那时俺刚好跨过OO的门槛,了解了一点UML的知识,不会被迷惑),就开始厌恶了某些虚假的论证,破绽百出的扬己抑彼,憎屋及乌,我从此对高的那套理论彻底失去了兴趣.
b.态度:态度决定一切,这是ml大叔给俺们留下的,呵,还有那几场自慰的比赛.我不知道还有多少同志把软件工程当万金油,如果还有,请清清嗓子,一起唱国际歌,或者到电影院去看人狼传说吧.
c.那几篇慷慨激昂的檄文,很可惜,没有说服力(我不想铺开讲,这是要花时间和精力的,俺可不是随随便便可以找几个蹩脚的理由来信口雌黄的人,所以只说结论),我看后的几个感受:(1)请高去学习语文,学学论文怎么写(2)请高参加一个UML培训班,先端正一下几个概念(前一段不是有兄弟要做培训么?)(3)赶快派其出国考察一下外国同行们的学术态度.
不过,俺想,第三项出国考察(旅游-借鸡生蛋)更诱惑人吧.
d.制度的弊病:863,呵呵,俺毕设搞的这个.坦率说,除了觉得俺们的怀老师还是值得仰视的以外,俺对863那个东西,彻底失去了尊敬的态度.说白了,俺怀疑这套学术体制的成果只能是怪胎.不知道高的东西,是否能和UML那套市场体制下的产物去抢市场.
e.ft,要去睡觉了,明天不想再迟到:(,仔细想想,CSDN上好多同志的论证水平确实有待提高(啊哈,包括我),这样的思维去搞什么需求,系分,设计,中国的软件水平能提高吗?还是和俺一样,先老老实实地当程序员吧:>
f.(24早)补充一点感受:(1)在实践中学习检验理论,而不要在理论中不痛不瘍的实践.(2)用UML来做反向软件工程,不要用UML来做正向软件工程.
最后再扔出俺的座右铭:
天行健,君子以自强不息.
地势坤,贤者唯厚德载物.
大白话座右铭:
踏踏实实做事,
老老实实做人.
2002/12/23 23:23 end
2.从上周又翻出了XP Install来找一些理论,还捎带复习一些编译方面的理论.
3.最近在努力阅读着ROC++,练习着FengYuan的那本WindowsGDI的宝典的例子,还要看完WEUC,并努力完成着我们的那个项目.
所以,很忙.不过,既然有同志要谈高,我就插下嘴,给大家揭示有这么一种态度:
a.我从每期必买的程序员上(不过,12期的不想买,不知道以后的能不能再勾起我的兴趣)早就拜读了高的文章.很早的时候,我看不懂;过了一阵,从大三下学期发奋地看软件工程的东西,可以渐渐理解了某些文章的只言片语,不过,大部分还是没有实践经验对照,还是不懂,俺就想,是不是水平不够呢,我要努力;但,从高对UML的攻击到发明了所谓的2G的OO(还好,那时俺刚好跨过OO的门槛,了解了一点UML的知识,不会被迷惑),就开始厌恶了某些虚假的论证,破绽百出的扬己抑彼,憎屋及乌,我从此对高的那套理论彻底失去了兴趣.
b.态度:态度决定一切,这是ml大叔给俺们留下的,呵,还有那几场自慰的比赛.我不知道还有多少同志把软件工程当万金油,如果还有,请清清嗓子,一起唱国际歌,或者到电影院去看人狼传说吧.
c.那几篇慷慨激昂的檄文,很可惜,没有说服力(我不想铺开讲,这是要花时间和精力的,俺可不是随随便便可以找几个蹩脚的理由来信口雌黄的人,所以只说结论),我看后的几个感受:(1)请高去学习语文,学学论文怎么写(2)请高参加一个UML培训班,先端正一下几个概念(前一段不是有兄弟要做培训么?)(3)赶快派其出国考察一下外国同行们的学术态度.
不过,俺想,第三项出国考察(旅游-借鸡生蛋)更诱惑人吧.
d.制度的弊病:863,呵呵,俺毕设搞的这个.坦率说,除了觉得俺们的怀老师还是值得仰视的以外,俺对863那个东西,彻底失去了尊敬的态度.说白了,俺怀疑这套学术体制的成果只能是怪胎.不知道高的东西,是否能和UML那套市场体制下的产物去抢市场.
e.ft,要去睡觉了,明天不想再迟到:(,仔细想想,CSDN上好多同志的论证水平确实有待提高(啊哈,包括我),这样的思维去搞什么需求,系分,设计,中国的软件水平能提高吗?还是和俺一样,先老老实实地当程序员吧:>
f.(24早)补充一点感受:(1)在实践中学习检验理论,而不要在理论中不痛不瘍的实践.(2)用UML来做反向软件工程,不要用UML来做正向软件工程.
最后再扔出俺的座右铭:
天行健,君子以自强不息.
地势坤,贤者唯厚德载物.
大白话座右铭:
踏踏实实做事,
老老实实做人.
2002/12/23 23:23 end
ozzzzzz 2002-12-20
- 打赏
- 举报
cajon(Cajon)
就是我说的那本啊
就是我说的那本啊
Colin-Han 2002-12-20
- 打赏
- 举报
刚刚看完 SHIZUMARU(绯雨闲丸) 贴出的文章，真精彩，希望能够有更多的看看.......
期待，书名叫什么？有没有中文版的在市面上销售？
期待，书名叫什么？有没有中文版的在市面上销售？
Colin-Han 2002-12-20
- 打赏
- 举报
o， 有没有全书的电子版？或者书？找来看看！
to SHIZUMARU(绯雨闲丸):
实在小弟是新来的，不知大虾大名，还望见谅！！！！
to SHIZUMARU(绯雨闲丸):
实在小弟是新来的，不知大虾大名，还望见谅！！！！
gucs 2002-12-19
- 打赏
- 举报
gz
twinsant124 2002-12-19
- 打赏
- 举报
refactoring & refine
en.
en.
ozzzzzz 2002-12-19
- 打赏
- 举报
这要怪蚂蚁 我以为他会告诉你
嘿嘿 我的朋友翻译了这章 马上就和我说 还学习重构干吗 学了也学不会 至少看了这本书kent都说你还不能说学会了重构 不是重构太难了 而是设计太难了
嘿嘿 我的朋友翻译了这章 马上就和我说 还学习重构干吗 学了也学不会 至少看了这本书kent都说你还不能说学会了重构 不是重构太难了 而是设计太难了
SHIZUMARU 2002-12-19
- 打赏
- 举报
有这等好帖，蚂蚁兄和o6z居然都不告诉我，不可原谅……而且楼主居然没有邀请我，更加不可原谅……
:) 下面贴一段文字，是Refactoring书的第15章（最后一章）的前面部分，应该可以解答楼主的问题。不能帖得更多，否则良心要不安了。
--------
現在，你已經擁有了這套七巧板的每一塊：你已經瞭解了重構的基礎，也知道了重構的分類，還實踐了所有這些重構。同時，你已經很擅長測試了，所以你不再畏首畏尾。現在，你可能會想：“我已經知道如何重構了。”不，還沒有。
前面列出的技術僅僅是一個起點，是你登堂入室之前的大門。如果沒有這些技術，你根本無法對運行中的程式進行任何設計上的改動。有了這些技術，你仍然做不到，但起碼可以開始嘗試了。
這些技術是如此精彩，可它們却僅僅是一個開始，這是爲什麽？答案很簡單：因爲你還不知道何時應該使用它們、何時不應該使用、何時開始、何時停止、何時前進、何時等待。使重構能够成功的，不是前面各各分立的技術，而是這種節奏。
當你真正懂得這一切時，你又怎麽知道呢？當你開始冷靜下來時，你就知道：自己已經真正“得道”了。到那時，你會有絕對的自信：不論別人留下的代碼有多麽雜亂無章，你都可以將它變好，好到足以進行後續的開發。
不過，在大多數時候，“得道”的標志是：你可以自信地停止重構。在重構者的整個表演中，“停止”正是壓軸的大戲。在開始時，你爲自己選擇一個大的目標——例如“去掉一堆不必要的子類”。然後，你開始向著這個目標前進，每一步都走得小而堅定，每一步都得到測試的有力支援。你離目標越來越近了，現在只剩兩個方法需要合幷了。終于，這兩個方法也被你搞定了。
就在此時，意想不到的事情發生了：你再也無法前進一步。也許是因爲時間太晚，你太疲倦了；也許是因爲你一開始的判斷就錯了，實際上不可能去掉所有的子類；也許是因爲沒有足够的測試來支援你。總而言之，你的自信已經灰飛烟滅了，你無法再自信滿滿地跨出下一步。你認爲自己不會把任何東西搞亂，但也無法確定。
這就是應該停下的時候了。如果代碼已經比開始時好，那麽就把它集成到系統中，發布你現在的成果。如果代碼幷沒有變好，就果斷地放弃這些無用的工作，回到開始的地方。然後，爲自己學到一課而高興，爲這次重構沒有成功而抱憾。那麽，明天怎麽辦？
明天，或者後天，或者下個月，甚至可能是明年，靈感總會來的——爲了等待進行一個重構的後一半所需的靈感，我最多曾經等過九個月。你可能會明白自己錯在哪里，也可能明白自己對在哪里，總之都會使你想清楚下一個步驟如何進行。然後，你就可以像最初一樣自信地跨出這一步。也許你羞愧地想：“我太笨了，竟然這麽久都沒想到這一步。”大可不必，每個人都是這樣的。
這有點像在懸崖峭壁上的小徑上行走：只要有光，你就可以前進，雖然謹慎却仍然自信；但是，一旦太陽落了山，你就應該停下來；在晚上，你應該睡個覺，幷且相信明天早晨太陽仍舊會升起。
這聽起來似乎有點玄乎其玄的味道。從感覺上來說，的確如此，因爲這是一種全新的編程方式。當你真正理解了重構之後，系統的設計對于你來說就好象源代碼文件中的字元那樣可以隨心所欲地操控。你可以直接地感覺到整個的設計，可以清楚地看到如何將其變得更靈活，也可以看到如何修改它——這樣修改一點，于是就可以這樣做；那樣修改一點，于是就可以那樣做。
但是，從另一個角度來說，這也幷非完全玄乎其玄的。重構是一種可以學習的技術，你可以在本書中讀到幷學習它的各個組成部分。然後，你只要把這些技術天衣無縫地結合在一起，就可以從一個全新的角度來看待軟體的開發。
:) 下面贴一段文字，是Refactoring书的第15章（最后一章）的前面部分，应该可以解答楼主的问题。不能帖得更多，否则良心要不安了。
--------
現在，你已經擁有了這套七巧板的每一塊：你已經瞭解了重構的基礎，也知道了重構的分類，還實踐了所有這些重構。同時，你已經很擅長測試了，所以你不再畏首畏尾。現在，你可能會想：“我已經知道如何重構了。”不，還沒有。
前面列出的技術僅僅是一個起點，是你登堂入室之前的大門。如果沒有這些技術，你根本無法對運行中的程式進行任何設計上的改動。有了這些技術，你仍然做不到，但起碼可以開始嘗試了。
這些技術是如此精彩，可它們却僅僅是一個開始，這是爲什麽？答案很簡單：因爲你還不知道何時應該使用它們、何時不應該使用、何時開始、何時停止、何時前進、何時等待。使重構能够成功的，不是前面各各分立的技術，而是這種節奏。
當你真正懂得這一切時，你又怎麽知道呢？當你開始冷靜下來時，你就知道：自己已經真正“得道”了。到那時，你會有絕對的自信：不論別人留下的代碼有多麽雜亂無章，你都可以將它變好，好到足以進行後續的開發。
不過，在大多數時候，“得道”的標志是：你可以自信地停止重構。在重構者的整個表演中，“停止”正是壓軸的大戲。在開始時，你爲自己選擇一個大的目標——例如“去掉一堆不必要的子類”。然後，你開始向著這個目標前進，每一步都走得小而堅定，每一步都得到測試的有力支援。你離目標越來越近了，現在只剩兩個方法需要合幷了。終于，這兩個方法也被你搞定了。
就在此時，意想不到的事情發生了：你再也無法前進一步。也許是因爲時間太晚，你太疲倦了；也許是因爲你一開始的判斷就錯了，實際上不可能去掉所有的子類；也許是因爲沒有足够的測試來支援你。總而言之，你的自信已經灰飛烟滅了，你無法再自信滿滿地跨出下一步。你認爲自己不會把任何東西搞亂，但也無法確定。
這就是應該停下的時候了。如果代碼已經比開始時好，那麽就把它集成到系統中，發布你現在的成果。如果代碼幷沒有變好，就果斷地放弃這些無用的工作，回到開始的地方。然後，爲自己學到一課而高興，爲這次重構沒有成功而抱憾。那麽，明天怎麽辦？
明天，或者後天，或者下個月，甚至可能是明年，靈感總會來的——爲了等待進行一個重構的後一半所需的靈感，我最多曾經等過九個月。你可能會明白自己錯在哪里，也可能明白自己對在哪里，總之都會使你想清楚下一個步驟如何進行。然後，你就可以像最初一樣自信地跨出這一步。也許你羞愧地想：“我太笨了，竟然這麽久都沒想到這一步。”大可不必，每個人都是這樣的。
這有點像在懸崖峭壁上的小徑上行走：只要有光，你就可以前進，雖然謹慎却仍然自信；但是，一旦太陽落了山，你就應該停下來；在晚上，你應該睡個覺，幷且相信明天早晨太陽仍舊會升起。
這聽起來似乎有點玄乎其玄的味道。從感覺上來說，的確如此，因爲這是一種全新的編程方式。當你真正理解了重構之後，系統的設計對于你來說就好象源代碼文件中的字元那樣可以隨心所欲地操控。你可以直接地感覺到整個的設計，可以清楚地看到如何將其變得更靈活，也可以看到如何修改它——這樣修改一點，于是就可以這樣做；那樣修改一點，于是就可以那樣做。
但是，從另一個角度來說，這也幷非完全玄乎其玄的。重構是一種可以學習的技術，你可以在本書中讀到幷學習它的各個組成部分。然後，你只要把這些技術天衣無縫地結合在一起，就可以從一個全新的角度來看待軟體的開發。
SHIZUMARU 2002-12-19
- 打赏
- 举报
有这等好帖，蚂蚁兄和o6z居然都不告诉我，不可原谅……而且楼主居然没有邀请我，更加不可原谅……
:) 下面贴一段文字，是Refactoring书的第15章（最后一章）的前面部分，应该可以解答楼主的问题。不能帖得更多，否则良心要不安了。
--------
現在，你已經擁有了這套七巧板的每一塊：你已經瞭解了重構的基礎，也知道了重構的分類，還實踐了所有這些重構。同時，你已經很擅長測試了，所以你不再畏首畏尾。現在，你可能會想：“我已經知道如何重構了。”不，還沒有。
前面列出的技術僅僅是一個起點，是你登堂入室之前的大門。如果沒有這些技術，你根本無法對運行中的程式進行任何設計上的改動。有了這些技術，你仍然做不到，但起碼可以開始嘗試了。
這些技術是如此精彩，可它們却僅僅是一個開始，這是爲什麽？答案很簡單：因爲你還不知道何時應該使用它們、何時不應該使用、何時開始、何時停止、何時前進、何時等待。使重構能够成功的，不是前面各各分立的技術，而是這種節奏。
當你真正懂得這一切時，你又怎麽知道呢？當你開始冷靜下來時，你就知道：自己已經真正“得道”了。到那時，你會有絕對的自信：不論別人留下的代碼有多麽雜亂無章，你都可以將它變好，好到足以進行後續的開發。
不過，在大多數時候，“得道”的標志是：你可以自信地停止重構。在重構者的整個表演中，“停止”正是壓軸的大戲。在開始時，你爲自己選擇一個大的目標——例如“去掉一堆不必要的子類”。然後，你開始向著這個目標前進，每一步都走得小而堅定，每一步都得到測試的有力支援。你離目標越來越近了，現在只剩兩個方法需要合幷了。終于，這兩個方法也被你搞定了。
就在此時，意想不到的事情發生了：你再也無法前進一步。也許是因爲時間太晚，你太疲倦了；也許是因爲你一開始的判斷就錯了，實際上不可能去掉所有的子類；也許是因爲沒有足够的測試來支援你。總而言之，你的自信已經灰飛烟滅了，你無法再自信滿滿地跨出下一步。你認爲自己不會把任何東西搞亂，但也無法確定。
這就是應該停下的時候了。如果代碼已經比開始時好，那麽就把它集成到系統中，發布你現在的成果。如果代碼幷沒有變好，就果斷地放弃這些無用的工作，回到開始的地方。然後，爲自己學到一課而高興，爲這次重構沒有成功而抱憾。那麽，明天怎麽辦？
明天，或者後天，或者下個月，甚至可能是明年，靈感總會來的——爲了等待進行一個重構的後一半所需的靈感，我最多曾經等過九個月。你可能會明白自己錯在哪里，也可能明白自己對在哪里，總之都會使你想清楚下一個步驟如何進行。然後，你就可以像最初一樣自信地跨出這一步。也許你羞愧地想：“我太笨了，竟然這麽久都沒想到這一步。”大可不必，每個人都是這樣的。
這有點像在懸崖峭壁上的小徑上行走：只要有光，你就可以前進，雖然謹慎却仍然自信；但是，一旦太陽落了山，你就應該停下來；在晚上，你應該睡個覺，幷且相信明天早晨太陽仍舊會升起。
這聽起來似乎有點玄乎其玄的味道。從感覺上來說，的確如此，因爲這是一種全新的編程方式。當你真正理解了重構之後，系統的設計對于你來說就好象源代碼文件中的字元那樣可以隨心所欲地操控。你可以直接地感覺到整個的設計，可以清楚地看到如何將其變得更靈活，也可以看到如何修改它——這樣修改一點，于是就可以這樣做；那樣修改一點，于是就可以那樣做。
但是，從另一個角度來說，這也幷非完全玄乎其玄的。重構是一種可以學習的技術，你可以在本書中讀到幷學習它的各個組成部分。然後，你只要把這些技術天衣無縫地結合在一起，就可以從一個全新的角度來看待軟體的開發。
:) 下面贴一段文字，是Refactoring书的第15章（最后一章）的前面部分，应该可以解答楼主的问题。不能帖得更多，否则良心要不安了。
--------
現在，你已經擁有了這套七巧板的每一塊：你已經瞭解了重構的基礎，也知道了重構的分類，還實踐了所有這些重構。同時，你已經很擅長測試了，所以你不再畏首畏尾。現在，你可能會想：“我已經知道如何重構了。”不，還沒有。
前面列出的技術僅僅是一個起點，是你登堂入室之前的大門。如果沒有這些技術，你根本無法對運行中的程式進行任何設計上的改動。有了這些技術，你仍然做不到，但起碼可以開始嘗試了。
這些技術是如此精彩，可它們却僅僅是一個開始，這是爲什麽？答案很簡單：因爲你還不知道何時應該使用它們、何時不應該使用、何時開始、何時停止、何時前進、何時等待。使重構能够成功的，不是前面各各分立的技術，而是這種節奏。
當你真正懂得這一切時，你又怎麽知道呢？當你開始冷靜下來時，你就知道：自己已經真正“得道”了。到那時，你會有絕對的自信：不論別人留下的代碼有多麽雜亂無章，你都可以將它變好，好到足以進行後續的開發。
不過，在大多數時候，“得道”的標志是：你可以自信地停止重構。在重構者的整個表演中，“停止”正是壓軸的大戲。在開始時，你爲自己選擇一個大的目標——例如“去掉一堆不必要的子類”。然後，你開始向著這個目標前進，每一步都走得小而堅定，每一步都得到測試的有力支援。你離目標越來越近了，現在只剩兩個方法需要合幷了。終于，這兩個方法也被你搞定了。
就在此時，意想不到的事情發生了：你再也無法前進一步。也許是因爲時間太晚，你太疲倦了；也許是因爲你一開始的判斷就錯了，實際上不可能去掉所有的子類；也許是因爲沒有足够的測試來支援你。總而言之，你的自信已經灰飛烟滅了，你無法再自信滿滿地跨出下一步。你認爲自己不會把任何東西搞亂，但也無法確定。
這就是應該停下的時候了。如果代碼已經比開始時好，那麽就把它集成到系統中，發布你現在的成果。如果代碼幷沒有變好，就果斷地放弃這些無用的工作，回到開始的地方。然後，爲自己學到一課而高興，爲這次重構沒有成功而抱憾。那麽，明天怎麽辦？
明天，或者後天，或者下個月，甚至可能是明年，靈感總會來的——爲了等待進行一個重構的後一半所需的靈感，我最多曾經等過九個月。你可能會明白自己錯在哪里，也可能明白自己對在哪里，總之都會使你想清楚下一個步驟如何進行。然後，你就可以像最初一樣自信地跨出這一步。也許你羞愧地想：“我太笨了，竟然這麽久都沒想到這一步。”大可不必，每個人都是這樣的。
這有點像在懸崖峭壁上的小徑上行走：只要有光，你就可以前進，雖然謹慎却仍然自信；但是，一旦太陽落了山，你就應該停下來；在晚上，你應該睡個覺，幷且相信明天早晨太陽仍舊會升起。
這聽起來似乎有點玄乎其玄的味道。從感覺上來說，的確如此，因爲這是一種全新的編程方式。當你真正理解了重構之後，系統的設計對于你來說就好象源代碼文件中的字元那樣可以隨心所欲地操控。你可以直接地感覺到整個的設計，可以清楚地看到如何將其變得更靈活，也可以看到如何修改它——這樣修改一點，于是就可以這樣做；那樣修改一點，于是就可以那樣做。
但是，從另一個角度來說，這也幷非完全玄乎其玄的。重構是一種可以學習的技術，你可以在本書中讀到幷學習它的各個組成部分。然後，你只要把這些技術天衣無縫地結合在一起，就可以從一個全新的角度來看待軟體的開發。
Jacode 2002-12-19
- 打赏
- 举报
up
AiWangji 2002-12-18
- 打赏
- 举报
非常抱歉，最后一段有一点乱，重发一下。
至于重构会不会引起“过度重构”。记得我过去讲过，XP方法强调所有重构
必须通过测试验证，也就是说经重构后的设计，必须通过原设计所通过的所有
测试例子，这样就保证了重构的完整性；并且保证重构后的设计至少是优于原
设计的。这样进行的重构哪怕多进行几次至少方向不会错误。而“过度设计”
就不是这样子了，因为它缺少验证，在脑中或纸上的过度设计可能会背离原来
的设计目标，使设计离目标越来越远。当然重构也是要讲究方法的，有关重构
的理论有很多，这里就不再展开了。
至于重构会不会引起“过度重构”。记得我过去讲过，XP方法强调所有重构
必须通过测试验证，也就是说经重构后的设计，必须通过原设计所通过的所有
测试例子，这样就保证了重构的完整性；并且保证重构后的设计至少是优于原
设计的。这样进行的重构哪怕多进行几次至少方向不会错误。而“过度设计”
就不是这样子了，因为它缺少验证，在脑中或纸上的过度设计可能会背离原来
的设计目标，使设计离目标越来越远。当然重构也是要讲究方法的，有关重构
的理论有很多，这里就不再展开了。
AiWangji 2002-12-18
- 打赏
- 举报
to cajon (Cajon) :
称我前辈实在不敢当。其实从我第一次到这里来到现在还不到半年的时间呢。
并且最近上CSDN的时间越来越少，发言也越来越少了。
既然发言了，也就不客套了，直接纠正你一个提法。
“在XP中，并不鼓励建立一个灵活的可扩展的架构。”
其实这是你对XP方法的一个误解。正确的提法是：XP方法不鼓励刻意地去
追求建立一个灵活的可扩展的架构。因为XP方法认为一个灵活的可扩展的架构
是可遇而不可求的。因为XP方法认为要构造一个灵活的可扩展的架构是要对问题
域有一个很深入的认识，而认识是一个循序渐进的过程，是需要检验的过程，
是不可能一步到位的。它是需要通过我们对问题域所包含的概念模型进行反复
理解，反复验证，反复重构后才能得到的。基于此XP方法并不鼓励在没有验证
之前化很多时间凭空构造一个所谓的“灵活的可扩展的架构”。而是鼓励在
我们已经认识的范围内构造一个较好的并且是可行的架构，然后不断通过实例
来验证它，发现问题重构它，直至自然地得到一个“灵活的可扩展的架构”。
不知道你对现在被公认的具有良好可扩展性的MVC架构有多少了解。其实象
这样的典型架构，也是一步一步发展而来的，但讲大的演变，也至少可以分为
三代。从最初smalltalk语言的GUI应用中的一个概念，经过第一代的强控制型，
到第二代的依赖型，直到发展到现在最新的可嵌入型，每一步都是经大量验证
后发现原有架构的不合理之处，进行重构后而得到的。并且MVC架构变得越来
越小巧（简单），越来越具有可扩展性，MVC架构的应用范围现在已经远远不止
一个GUI应用了。
总结一下，XP方法不提倡凭空构建一个“灵活的可扩展的架构”，它鼓励用
重构的方法来渐进式的（较自然地）得到一个最“简单的设计”。而“简单的
设计”也就是内涵最小的设计，我们知道内涵越小，外延必然越大，也就是
可扩展性越好。所以说XP方法追求的“简单的设计”其实就是你讲的
“灵活的可扩展的架构”了。你的提法是不正确的，只是XP方法强调这样的
设计必须通过验证，通过重构逐渐地得到，而不是一上来就凭空想象，一步
到位（其实在复杂的问题域中，这是做不到的）。
至于重构会不会引起“过度重构”。记得我过去讲过，XP方法强调所有重构必须
通过测试验证，也就是说经重构后的设计，必须通过原设计所通过的所有例子。这样就保证了重构是完整的，并且至少是由于原设计的。这样的重构哪怕多进行几次
至少方向不会错误。而“过度设计”就不是这样了，因为它缺少验证，所以过度的
设计可能背离原来的目标，使我们走的越来越远。当然重构也是要讲方法的，有关
重构的理论有很多，这里就不再展开了。
不知道以上的回答让你满意没有。
称我前辈实在不敢当。其实从我第一次到这里来到现在还不到半年的时间呢。
并且最近上CSDN的时间越来越少，发言也越来越少了。
既然发言了，也就不客套了，直接纠正你一个提法。
“在XP中，并不鼓励建立一个灵活的可扩展的架构。”
其实这是你对XP方法的一个误解。正确的提法是：XP方法不鼓励刻意地去
追求建立一个灵活的可扩展的架构。因为XP方法认为一个灵活的可扩展的架构
是可遇而不可求的。因为XP方法认为要构造一个灵活的可扩展的架构是要对问题
域有一个很深入的认识，而认识是一个循序渐进的过程，是需要检验的过程，
是不可能一步到位的。它是需要通过我们对问题域所包含的概念模型进行反复
理解，反复验证，反复重构后才能得到的。基于此XP方法并不鼓励在没有验证
之前化很多时间凭空构造一个所谓的“灵活的可扩展的架构”。而是鼓励在
我们已经认识的范围内构造一个较好的并且是可行的架构，然后不断通过实例
来验证它，发现问题重构它，直至自然地得到一个“灵活的可扩展的架构”。
不知道你对现在被公认的具有良好可扩展性的MVC架构有多少了解。其实象
这样的典型架构，也是一步一步发展而来的，但讲大的演变，也至少可以分为
三代。从最初smalltalk语言的GUI应用中的一个概念，经过第一代的强控制型，
到第二代的依赖型，直到发展到现在最新的可嵌入型，每一步都是经大量验证
后发现原有架构的不合理之处，进行重构后而得到的。并且MVC架构变得越来
越小巧（简单），越来越具有可扩展性，MVC架构的应用范围现在已经远远不止
一个GUI应用了。
总结一下，XP方法不提倡凭空构建一个“灵活的可扩展的架构”，它鼓励用
重构的方法来渐进式的（较自然地）得到一个最“简单的设计”。而“简单的
设计”也就是内涵最小的设计，我们知道内涵越小，外延必然越大，也就是
可扩展性越好。所以说XP方法追求的“简单的设计”其实就是你讲的
“灵活的可扩展的架构”了。你的提法是不正确的，只是XP方法强调这样的
设计必须通过验证，通过重构逐渐地得到，而不是一上来就凭空想象，一步
到位（其实在复杂的问题域中，这是做不到的）。
至于重构会不会引起“过度重构”。记得我过去讲过，XP方法强调所有重构必须
通过测试验证，也就是说经重构后的设计，必须通过原设计所通过的所有例子。这样就保证了重构是完整的，并且至少是由于原设计的。这样的重构哪怕多进行几次
至少方向不会错误。而“过度设计”就不是这样了，因为它缺少验证，所以过度的
设计可能背离原来的目标，使我们走的越来越远。当然重构也是要讲方法的，有关
重构的理论有很多，这里就不再展开了。
不知道以上的回答让你满意没有。
twinsant124 2002-12-18
- 打赏
- 举报
http://www-900.ibm.com/developerWorks/cn/java/l-refactory/index.shtml
hehe.
hehe.
twinsant124 2002-12-18
- 打赏
- 举报
mark
ozzzzzz 2002-12-18
- 打赏
- 举报
cajon(Cajon)
那本书现在正在候杰和透明的努力下翻译 你可以找了看看他们翻译的第一章
坏气味有多种 书里有介绍
设备就是计算机啊 因为重构的时候需要不断的进行集成测试
重构应该尽量少的改变接口 测试必须通过原来所有的测试(除非原来的测试有问题 或者所针对的部分已经不存在－－也就是那部分代码被删除了而不是被代替了）
我说一个标准 比如大小的问题 一个屏幕就是基线 超过就是大了
那本书现在正在候杰和透明的努力下翻译 你可以找了看看他们翻译的第一章
坏气味有多种 书里有介绍
设备就是计算机啊 因为重构的时候需要不断的进行集成测试
重构应该尽量少的改变接口 测试必须通过原来所有的测试(除非原来的测试有问题 或者所针对的部分已经不存在－－也就是那部分代码被删除了而不是被代替了）
我说一个标准 比如大小的问题 一个屏幕就是基线 超过就是大了
Colin-Han 2002-12-18
- 打赏
- 举报
另外，重构很可能会修改其中部分代码的接口，这样，测试也必须重新修改，这样不是也很不爽！如果没有结对编程，我想程序员还是会产生抵触情绪的，毕竟实现功能比编写测试更有成就感。
Colin-Han 2002-12-18
- 打赏
- 举报
谢谢ozzzzzz：
您提到的7点，确实让我受益匪浅，对于你提到的那本书，是否有中文版的？我的E文实在很差。
对于你的第4条，重构需要良好的设备的配合，能够说得细一些？我实在看不出需要什么样的设备。
能否简单介绍一下你们小组对于坏气味的标准，它都包含哪些方面？XP中坏气味的一种是重复的代码（Once and Only Once),对于这一点，是不是只能靠程序员自己去发现？还有没有其他的坏气味？
我现在就要接受一个烂尾工程，考虑可能需要整体的重构，但是，估计公司领导可能会难以接受......伤心......
您提到的7点，确实让我受益匪浅，对于你提到的那本书，是否有中文版的？我的E文实在很差。
对于你的第4条，重构需要良好的设备的配合，能够说得细一些？我实在看不出需要什么样的设备。
能否简单介绍一下你们小组对于坏气味的标准，它都包含哪些方面？XP中坏气味的一种是重复的代码（Once and Only Once),对于这一点，是不是只能靠程序员自己去发现？还有没有其他的坏气味？
我现在就要接受一个烂尾工程，考虑可能需要整体的重构，但是，估计公司领导可能会难以接受......伤心......
termite 2002-12-18
- 打赏
- 举报
good!
加载更多回复（3）
