锁定老帖子 主题:重构的几大重要特点
该帖已经被评为新手帖
|
|
---|---|
作者 | 正文 |
发表时间:2010-04-09
抛出异常的爱 写道 没有测试代码。
重构就是在自杀。 5.重构的保证:测试。 说的不错! |
|
返回顶楼 | |
发表时间:2010-04-09
抛出异常的爱 写道 没有测试代码。
重构就是在自杀。 说明你看那本书看得不够深入 用这个思路你就会进入一个死结: 最需要重构的那些代码是没有测试并且很难加上测试的 结论就是最需要重构的代码你是没办法重构的 所以,你还得继续认真读那本书 |
|
返回顶楼 | |
发表时间:2010-04-09
gigix 写道 抛出异常的爱 写道 没有测试代码。
重构就是在自杀。 说明你看那本书看得不够深入 用这个思路你就会进入一个死结: 最需要重构的那些代码是没有测试并且很难加上测试的 结论就是最需要重构的代码你是没办法重构的 所以,你还得继续认真读那本书 已经有过重构那种项目的经历了 一开始不是太了解业务。 所以用的暴力DEBUG改了一个模块 太浪费时间 还有业务缺失。 再下来一点点拆代码。。。。。 但还是认为真是个磨灭人性的方式。 |
|
返回顶楼 | |
发表时间:2010-04-10
最后修改:2010-04-10
抛出异常的爱 写道 已经有过重构那种项目的经历了
一开始不是太了解业务。 所以用的暴力DEBUG改了一个模块 太浪费时间 还有业务缺失。 再下来一点点拆代码。。。。。 但还是认为真是个磨灭人性的方式。 你去看我给那本书新写的序 重构的关键不仅是不改变程序行为 更重要的是不需要了解程序行为 你记熟了那些重构手法之后,动手去做的过程完全是形式化的,出错的几率很小,这样你才能安全地做出第一步重构,拆出一些较小的单元,加上测试,然后继续深入 当然这个“记熟”就不仅仅是记得一点“思想”或者知道这些重构手法的名字 你必须记住重构手法的每一个实施步骤 这个道理,我在几年里把那本书读了十几遍才真正明白的 |
|
返回顶楼 | |
发表时间:2010-04-10
gigix 写道 抛出异常的爱 写道 已经有过重构那种项目的经历了
一开始不是太了解业务。 所以用的暴力DEBUG改了一个模块 太浪费时间 还有业务缺失。 再下来一点点拆代码。。。。。 但还是认为真是个磨灭人性的方式。 你去看我给那本书新写的序 重构的关键不仅是不改变程序行为 更重要的是不需要了解程序行为 你记熟了那些重构手法之后,动手去做的过程完全是形式化的,出错的几率很小,这样你才能安全地做出第一步重构,拆出一些较小的单元,加上测试,然后继续深入 当然这个“记熟”就不仅仅是记得一点“思想”或者知道这些重构手法的名字 你必须记住重构手法的每一个实施步骤 这个道理,我在几年里把那本书读了十几遍才真正明白的 你是说我不需要去考虑逻辑直接用这些手法来作? 考虑逻辑是我重构过程中最主要的工作。。。。 占工作时间的4/5左右。。。。 这的确是需要用勇气的地方。 |
|
返回顶楼 | |
发表时间:2010-04-10
最后修改:2010-04-10
抛出异常的爱 写道 你是说我不需要去考虑逻辑直接用这些手法来作?
考虑逻辑是我重构过程中最主要的工作。。。。 占工作时间的4/5左右。。。。 这的确是需要用勇气的地方。 不是勇气,而是相信科学 整个重构这件事,是建立在William Opdyke的博士论文基础上的,那篇论文最重要的东西就是在讲行为保持的程序修改手法 有一些修改手法是行为保持的。行为保持的修改手法的叠加是行为保持的。这是已经被证明的原理。 所以你需要首先记住一些常用的行为保持的修改手法,面对一个复杂的程序就直接用这些手法去修改它 这个过程中你清楚自己做的每一步不会对程序的行为造成任何改变 这靠的不是勇气,而是知识 你知道自己每一个动作是在做什么,就像你知道加上一行注释不会改变程序的行为一样 如果必须理解一段程序才能重构它,那你同样会陷入两难 最难重构的那段代码,你是没办法理解它的 之所以有那么多关于重构的奇谈怪论,其实很简单 因为太多人根本就不会重构 |
|
返回顶楼 | |
发表时间:2010-04-10
老抛露底了吧
|
|
返回顶楼 | |
发表时间:2010-04-10
最后修改:2010-04-10
tuti 写道 老抛露底了吧
露就露吧 知道了些前以前不知道的东西 以后可以少作点孽 重构这书以前也看过 再看一次吧。 对不住我上个项目的兄弟们 为了分析业务折磨了他们很长时间。 我的确有对需求丢失有恐惧症 去年一月份的一个项目作的那叫一个恶心。。。。 今年年初的一个项目的维护 几乎每次改BUG都像是重新开发一样 把所有可能的需求要REVIEW两次 成果还是被肯定的。 但代价是大多数时间在开会。 每天开发时间大约在2小时左右。 就是恐惧需求缺失。。。。 翻翻以前的贴子 发现gigix以前也说过这样的话。 但当时不是很理解。。。。 |
|
返回顶楼 | |
发表时间:2010-04-10
抛出异常的爱 写道 tuti 写道 老抛露底了吧
露就露吧 知道了些前以前不知道的东西 以后可以少作点孽 重构这书以前也看过 再看一次吧。 对不住我上个项目的兄弟们 为了分析业务折磨了他们很长时间。 我的确有对需求丢失有恐惧症 去年一月份的一个项目作的那叫一个恶心。。。。 今年年初的一个项目的维护 几乎每次改BUG都像是重新开发一样 把所有可能的需求要REVIEW两次 成果还是被肯定的。 但代价是大多数时间在开会。 每天开发时间大约在2小时左右。 就是恐惧需求缺失。。。。 翻翻以前的贴子 发现gigix以前也说过这样的话。 但当时不是很理解。。。。 你要明白为什么gigix说这个话 tw是做什么的? 到处宣称自己会魔法 可以解百病 tw还不至于厚着脸皮说自己可以精通所有行业的业务 但是他们又希望可以从所有行业里分一杯羹 于是他们想出个办法 说重构是一种高级魔法 可以无视魔防 无视障碍 并且这个世界上大部分人都彻底学不会这种魔法 -- 我估计重构的最佳实践就是加入tw 其实我相信存在这种魔法 因为它的本质是字符串的搜索和替换 换个函数名 或者把函数换个地方 诸如此类 但是 问题在于这种魔法有任何实际意义吗? 有-可以骗钱 但对于你,抛爱同志来说,你相信通过这种全局搜索替换字符串的把戏就可以解决代码中的bug或者潜在bug吗? 如果你只是想让代码看起来符合某些最佳实践,那么这种把戏的确可以做到-至少理论上是可以的 但是你要明白 代码的健壮性完备性效率靠的不是这些死板的规矩和重构工具 如果写代码的人不具备足够的经验和智商,那么这些重构的结果无非是从一个火坑跳到另外一个 tw接受了不少的来自各方面的怀疑 所以他们也发展出了抗体--害虫都有这种本事 他们的抗体就是 彻底否认行业经验对代码的影响 宣布一个人 只要坚决执行所谓重构的实践 那么哪怕他完全不懂代码的真实涵义-对现实的映射,他也可以提升代码质量 解决潜在bug 在宣称这个断言的同时 任何关于重构的、并且出版了的实际例子都是玩具例子 另外的间接例证是tw为多少多少大公司服务过 不知道你感觉如何 反正我是觉得这比皇帝的新衣好不到哪里去 我很有兴趣知道 如果面对一个因为一级缓存被污染而导致的效率下降的bug tw可以给出什么样的解决方案 如果一个因为12个核并发而导致的偶然发生的core,tw又能给出什么方案 tw不是宣称他们无需任何行业相关知识吗?不是说可以完全不理解代码的逻辑吗?那自然也不用理解缓存和pipeline了 我也不知道gigix到底是一个称职的tw人,或者不是。 因为一方面他不遗余力的为tw摇旗呐喊,一方面又反复的暴露tw的方针政策是多么的可笑 这算无间道吗? |
|
返回顶楼 | |
发表时间:2010-04-10
最后修改:2010-04-10
没有人宣称重构可以治百病。没有人宣称面向对象技术可以解决一切软件问题。
事实是从那本书开始,所有人都有一个明确的共识: 重构,面向对象技术,不针对并行程序设计 你可以到那本书里找到对应的引文。 自己立一个风车自己来打,很好玩是吧? 至于对于TW的那堆评论,简单回复如下: 医生会给交了医药费的病人诊疗,有时业余时间给朋友摸摸脉提提建议 至于不相干的陌生人“有兴趣知道”什么东西,其实医生没什么兴趣知道 |
|
返回顶楼 | |