- 浏览: 348884 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
guji528:
很好,清晰明了!
(8)python教程:几行代码搞定python 设计模式 -
poson:
为什么踩啊?
三言两语谈团队合作 -
andyhelberg:
你好,想请教一下关于应用敏捷开发在软件维护过程的经验。欢迎与我 ...
对scrum开发的感受 -
poson:
chenwq 写道可以提供behavior targeting ...
最近公司培训的算法 -
chenwq:
可以提供behavior targeting 相关材料不?先谢 ...
最近公司培训的算法
我们的代码,经常都有代码review。但是代码review之后,大家并没有大量的重构代码。主要原因是重构代码需要花太多的时间,而且还有再次测试,对于很少的项目时间来说,重构代码是很不划算的。
不过不重构代码,大家的代码质量又很难提高。不知道大家怎么办?
TDD太浪费时间?你是和什么比太浪费时间?和Debug比?和你的黑箱,白箱测试比?
既然你那么能省时间,何必感叹代码改动还测试成本太高?
SVN上文件如果是重构改名字导致的删除的话,历史都是保留的,跟着重构以后的文件走。
CVS不支持这个功能。
还有就是,真的是删除操作的话,之前的修改记录是找的回来的,就是比较麻烦而已。
其实,只要经过前期详细分析和设计,做好设计工作,中期在代码开发中坚决实施TDD,完全可以控制这种风险。
这样做,你完全可以开发一个新的系统了。难道你没有意识到,在你给出的这个过程中,存在着重重风险吗?你去做分析,原始需求文档怎么保证?实现中,很多系统根本就没有任何文档,所有的文档都在早期开发者的脑袋里。而且即使有,你也难以保障你分析的结果是无误的,只要实际验证、使用时才会发现是否存在问题……
TDD不是万能的,而且其中隐含一个前提:你必须理解需求!
一句话,对于某些项目:do not fix it until it is broken.
这个说法有些偏激,尤其是最后一句。相反,这种大运动量的重构,更需要行家里手才行,否则,质量无法保证,重构等于空谈。
看了很多回复,大部分都排斥大规模的重构。但是,如果是针对老代码,老架构进行重构呢,这难道就不叫重构,就不能重构了?不然,而是缺少这样的魄力去做,没人敢冒这风险。其实,只要经过前期详细分析和设计,做好设计工作,中期在代码开发中坚决实施TDD,完全可以控制这种风险。
我理解的重构,关键不在量的多少,频度的多少,而是是否能在代码稳定性,健壮性,效率上有提升。
当然,频繁的小粒度的重构或许是种比较好的方式。
重构在我看来是种看多代码需要变动的期权。
没有自动化测试,就不能重构了吗?
不太合理吧。自动化测试与重构有必然关系吗?
没有自动化测试你怎么确保可观察的行为不改变?rename一下然后人肉回归所有功能?
没有自动化测试,就不能重构了吗?
不太合理吧。自动化测试与重构有必然关系吗?
然后等客户说“第一期做得不错呀,你们接着做第二期吧”的时候抓栏杆撕床单
如果不用TTD一般的需求是怎么记录的?
用buglist这种方式有点冗余.
需求说明书又缺很多需求变更.
实在是不知道作二期的那群人
是怎么把一期的需求
从代码中扒出来的?
上个项目最失败的几点都是由于需求扒出来的时候走了样
按你说法 需求难道应该用tdd来保存?
真的不知道用什么来保存
上家上上家都是用人脑来保存这些信息......
然后等客户说“第一期做得不错呀,你们接着做第二期吧”的时候抓栏杆撕床单
如果不用TTD一般的需求是怎么记录的?
用buglist这种方式有点冗余.
需求说明书又缺很多需求变更.
实在是不知道作二期的那群人
是怎么把一期的需求
从代码中扒出来的?
上个项目最失败的几点都是由于需求扒出来的时候走了样
先出个需求说明书,然后分解成功能点或jira的task或用户故事或随便什么东西,
然后每次迭代实现一些功能,改一些bug,如此反复,直到没啥可做的了。
貌似跟tdd没啥关系。
不过不重构代码,大家的代码质量又很难提高。不知道大家怎么办?
评论
56 楼
tuti
2010-02-26
Durian 写道
1.反对TDD开发,太浪费时间,平时可以自己多做点黑盒,白合测试什么都有了。
2.适当的重构,不建议太大改动,测试成本太高。
2.适当的重构,不建议太大改动,测试成本太高。
TDD太浪费时间?你是和什么比太浪费时间?和Debug比?和你的黑箱,白箱测试比?
既然你那么能省时间,何必感叹代码改动还测试成本太高?
55 楼
lkj107
2010-02-26
上线的系统重构风险太大,一般是忽悠上二期的时候推倒重来
54 楼
poson
2009-12-26
1.反对TDD开发,太浪费时间,平时可以自己多做点黑盒,白合测试什么都有了。
2.适当的重构,不建议太大改动,测试成本太高。
确实是测试成本很高。别人帮我重构了代码,测试的时候发现一大堆问题。
不过自己经常重构,确实可以提高自己的编码水平。
2.适当的重构,不建议太大改动,测试成本太高。
Durian 写道
1.反对TDD开发,太浪费时间,平时可以自己多做点黑盒,白合测试什么都有了。
2.适当的重构,不建议太大改动,测试成本太高。
2.适当的重构,不建议太大改动,测试成本太高。
确实是测试成本很高。别人帮我重构了代码,测试的时候发现一大堆问题。
不过自己经常重构,确实可以提高自己的编码水平。
53 楼
Durian
2009-12-21
1.反对TDD开发,太浪费时间,平时可以自己多做点黑盒,白合测试什么都有了。
2.适当的重构,不建议太大改动,测试成本太高。
2.适当的重构,不建议太大改动,测试成本太高。
52 楼
xinnn
2009-09-16
重构代码是分层次和级别的,一般来说会有代码级的重构、模块级的重构和系统级的重构。
按照你的说法,你们的重构起码是模块级以上的了,如果是这样的话问题可能就会比较多了,很大一部分原因是系统模块的设计问题了,如果设计的兼容性比较差的话是会导致需要不断的做重构来适应需求的不断变化,而好的设计人员往往会提前在设计之时考虑到相关会涉及到的问题从而在设计方案中为潜在的问题和需求预留好解决的接口,不会导致系统出现大的改动,更不会有颠覆性的重构现象。
代码级的重构在功能实现之时就要自己来对涉及性能和复杂逻辑等问题进行代码重构了,而review的一个很重要的一点就是大家相互之间提出对代码的编写意见,其实质就是相互之间提出代码的重构意见。
总之,重构在项目质量的问题上时很重要的一环,具体来说重构在项目中的比重到底应该占多少,应该视对项目质量的比重而定,比如对时间比较紧的项目就可适当减少重构的比重。我曾做过连测试都没有就发布的项目,更不要说重构了,最要紧的问题是项目允许你的时间不够了。而重构代码绝对对你的代码编写能力的提高有帮助
按照你的说法,你们的重构起码是模块级以上的了,如果是这样的话问题可能就会比较多了,很大一部分原因是系统模块的设计问题了,如果设计的兼容性比较差的话是会导致需要不断的做重构来适应需求的不断变化,而好的设计人员往往会提前在设计之时考虑到相关会涉及到的问题从而在设计方案中为潜在的问题和需求预留好解决的接口,不会导致系统出现大的改动,更不会有颠覆性的重构现象。
代码级的重构在功能实现之时就要自己来对涉及性能和复杂逻辑等问题进行代码重构了,而review的一个很重要的一点就是大家相互之间提出对代码的编写意见,其实质就是相互之间提出代码的重构意见。
总之,重构在项目质量的问题上时很重要的一环,具体来说重构在项目中的比重到底应该占多少,应该视对项目质量的比重而定,比如对时间比较紧的项目就可适当减少重构的比重。我曾做过连测试都没有就发布的项目,更不要说重构了,最要紧的问题是项目允许你的时间不够了。而重构代码绝对对你的代码编写能力的提高有帮助
51 楼
ldd600
2009-08-04
遗留代码很难重构吧,只有在fix问题的时候,适当的重构,加入相关的单元测试。即使做新的cr,也不会对遗留代码中相关部分进行大规模重构,老大们的意思一般都是不出问题,就不要去改它。
50 楼
icewubin
2009-08-03
pipilu 写道
楼上说的那件事儿挺逗,笑死了。我觉得不提倡做删除操作,因为那个文件一删,那以前的修改记录就无迹可循了。
SVN上文件如果是重构改名字导致的删除的话,历史都是保留的,跟着重构以后的文件走。
CVS不支持这个功能。
还有就是,真的是删除操作的话,之前的修改记录是找的回来的,就是比较麻烦而已。
49 楼
rocwon
2009-07-31
要想把代码写好的话,重构无处不在
48 楼
liusu
2009-07-24
看这个讨论,才发现我已经步入重构强迫症的行列。 我是写几行代码就不舒服就想重构。方法命名,变量命名让我很纠结。是不是需要泛型,是不是要提个接口。。 哈哈
47 楼
chxkyy
2009-07-09
如果是web页面,怎么做测试?手工点?
46 楼
tibetjungle
2009-07-08
rappy 写道
其实,只要经过前期详细分析和设计,做好设计工作,中期在代码开发中坚决实施TDD,完全可以控制这种风险。
这样做,你完全可以开发一个新的系统了。难道你没有意识到,在你给出的这个过程中,存在着重重风险吗?你去做分析,原始需求文档怎么保证?实现中,很多系统根本就没有任何文档,所有的文档都在早期开发者的脑袋里。而且即使有,你也难以保障你分析的结果是无误的,只要实际验证、使用时才会发现是否存在问题……
TDD不是万能的,而且其中隐含一个前提:你必须理解需求!
一句话,对于某些项目:do not fix it until it is broken.
45 楼
lcllcl987
2009-07-07
我们经常号称在重构, 但干的却是重写的勾当。
我们的项目运行于乌托邦,所以可以这样。
哈哈
我们的项目运行于乌托邦,所以可以这样。
哈哈
44 楼
rappy
2009-07-06
mock1234 写道
不要把重构说成是一个重量级的企业开发文档开发步骤,那种理解是很荒唐的。XP的重构,是指发生在5~10分钟之内的那种操作,只有擅长每一次都高标准地完成看似短促、心血来潮就可以进行的重构才具有最大的威力,这个时候如果你的代码总是可以保持系统回归测试稳定性就可谓巅峰状态之作;而那些费了九牛二虎之力搞一场轰轰烈烈重构运动的笨重行为则反而不太擅长重构,初级水平、质量较低的开发人员就可以做这个事了。
这个说法有些偏激,尤其是最后一句。相反,这种大运动量的重构,更需要行家里手才行,否则,质量无法保证,重构等于空谈。
看了很多回复,大部分都排斥大规模的重构。但是,如果是针对老代码,老架构进行重构呢,这难道就不叫重构,就不能重构了?不然,而是缺少这样的魄力去做,没人敢冒这风险。其实,只要经过前期详细分析和设计,做好设计工作,中期在代码开发中坚决实施TDD,完全可以控制这种风险。
我理解的重构,关键不在量的多少,频度的多少,而是是否能在代码稳定性,健壮性,效率上有提升。
当然,频繁的小粒度的重构或许是种比较好的方式。
43 楼
seekgirl
2009-07-05
呵呵,项目经理要是没有这个意思,啥也白搭
42 楼
tuti
2009-07-03
eclipse2008 写道
是否重构那就要看性价比了。
重构在我看来是种看多代码需要变动的期权。
41 楼
eclipse2008
2009-07-02
是否重构那就要看性价比了。
40 楼
gigix
2009-07-02
pangyi 写道
tuti 写道
没自动测试,就不要扯什么重构。
没有自动化测试,就不能重构了吗?
不太合理吧。自动化测试与重构有必然关系吗?
Martin Fowler 写道
重构:在不改变代码可观察之行为的前提下修改代码结构以改善代码质量
没有自动化测试你怎么确保可观察的行为不改变?rename一下然后人肉回归所有功能?
39 楼
pangyi
2009-07-02
tuti 写道
没自动测试,就不要扯什么重构。
没有自动化测试,就不能重构了吗?
不太合理吧。自动化测试与重构有必然关系吗?
38 楼
抛出异常的爱
2009-07-02
seen 写道
抛出异常的爱 写道
gigix 写道
neptune 写道
注意:如果是大项目或长时间的项目,重构好。如果是小项目或一次的项目,不要冲动,重构是需要成本的。
然后等客户说“第一期做得不错呀,你们接着做第二期吧”的时候抓栏杆撕床单
如果不用TTD一般的需求是怎么记录的?
用buglist这种方式有点冗余.
需求说明书又缺很多需求变更.
实在是不知道作二期的那群人
是怎么把一期的需求
从代码中扒出来的?
上个项目最失败的几点都是由于需求扒出来的时候走了样
按你说法 需求难道应该用tdd来保存?
真的不知道用什么来保存
上家上上家都是用人脑来保存这些信息......
37 楼
daquan198163
2009-07-01
抛出异常的爱 写道
gigix 写道
neptune 写道
注意:如果是大项目或长时间的项目,重构好。如果是小项目或一次的项目,不要冲动,重构是需要成本的。
然后等客户说“第一期做得不错呀,你们接着做第二期吧”的时候抓栏杆撕床单
如果不用TTD一般的需求是怎么记录的?
用buglist这种方式有点冗余.
需求说明书又缺很多需求变更.
实在是不知道作二期的那群人
是怎么把一期的需求
从代码中扒出来的?
上个项目最失败的几点都是由于需求扒出来的时候走了样
先出个需求说明书,然后分解成功能点或jira的task或用户故事或随便什么东西,
然后每次迭代实现一些功能,改一些bug,如此反复,直到没啥可做的了。
貌似跟tdd没啥关系。
发表评论
-
论文阅读总结
2012-02-14 17:29 970以前阅读论文的套路:搜索、下载、阅读,如果好就打印出来, ... -
程序路径以及配置文件的习惯问题
2012-02-03 11:20 896每次用别人代码的时候,都希望从svn中check out出来就 ... -
常用书籍
2012-01-11 15:27 861Hadoop权威指南(第2版) [平装] http://ww ... -
批评很简单,解决问题很复杂
2011-09-13 10:22 1033在工作中发现问题很简单,你只要仔细看,你就可以发现大量的问题。 ... -
一个团队最首要的是士气
2011-07-06 09:15 726士气遭到打击,短期内很难恢复! 如果几个人士气低迷,很容易影响 ... -
身为程序员犯过的错误
2011-04-11 13:22 792以前犯过的错误时,从来不和主管沟通。 对项目的看法、思考,只 ... -
采取行动,解决问题
2010-08-01 14:42 882陶行知很久以前就说过”知易行难“,就是说我们很容易获取 ... -
数据推送总结
2010-07-25 09:50 1087当我们有一个应用,部署在多个服务器上。这些服务器每天都要更新数 ... -
提高工作效率的15个小技巧
2010-07-24 16:49 10291、多用电话沟通。用邮件可以讨论结果,用聊天工具很多时候只 ... -
如何提高执行力
2010-07-24 12:36 0当接受一个任务的时候,就需要千方百计的想办法完成任务。 -
将公共代码和业务平台分开
2010-07-20 12:36 917《走出软件作坊》一书的作者阿朱说,要把公共代码和业务平台 ... -
实在是太方便了----建议使用Chrome的AutoPager 插件
2010-07-18 23:42 1674AutoPager 插件可以对javaeye论坛帖子自动翻页, ... -
如何改进算法以及上线策略
2010-07-18 22:39 960在互联网行业,如果你有很多用户,当你稍微修改一下算法, ... -
实习生待遇怎么才合适
2010-07-18 19:27 1441很多人都说实习生的待遇如何如何的低,觉得实习生吃了很大 ... -
SCRUM Master如何处理插入需求
2010-07-15 20:55 887我们处在一个高速发展的时代。在中国做什么都要快,快才能 ... -
工作中无小事
2010-06-20 18:00 857工作中无小事。很多时候,在工作中无意间做错事情就会砸了自 ... -
用积极的状态工作
2010-04-17 12:43 830很多时候我觉得工作很累,觉得付出少于回报,觉得公司这样那 ... -
我们需要什么样的实习生?---面试感想
2010-04-13 08:45 2420以下针对数据挖掘的实习生,最近对两三个实习生面试之后的感想: ... -
为什么我不会写作文?
2010-01-12 22:14 2227小学的时候,写作 ... -
快乐工作
2010-01-03 17:34 818...
相关推荐
1. 重构的目的:为什么重构(why) 2. 重构的对象:重构什么(what) 3. 重构的时机:什么时候重构(when) 4. 重构的方法:如何重构(how)
代码到底该如何重构?.doc
重构是持续改进代码的基础。抵制重构将带来技术麻烦:忘记代码片段的功能、...其中大多数重构都可以在Refactoring.com中找到,有一些来自《代码大全(第2版)》,剩下的则是作者平时经常使用或收集自其他互联网资源。
重构改善既有代码的设计,重构改善既有代码的设计课件,重构改善既有代码的设计PPT
JAVA 代码重构 JAVA 代码重构 JAVA 代码重构 JAVA 代码重构 JAVA 代码重构
项目重构方案模板、项目重构方案模板ppt,项目重构方案计划模板
代码重构 重构与模式
学习型设计模式重构代码
代码重构
改善既有的代码重构(ppt),改善既有的代码重构,改善既有的代码重构PPT
NULL 博文链接:https://ivaneye.iteye.com/blog/365786
重构改善现有代码设计.pdf 重构改善现有代码设计.pdf
使用设计模式重构代码.pdf
压缩感知程序,很多经典CS重构算法程序。适合初学者学习使用。
重构——改善既有代码设计,经典文档,架构师必须教程
《重构 改善既有代码的设计》清晰揭示了重构的过程,解释了重构的原理和实践方式,并给出了何时以及何地应该开始挖掘代码以求改善。书中给出了70 多个可行的重构,每个重构都介绍了一种经过验证的代码变换手法的动机...
对经验模态分解后的各分量IMF进行重构代码,函数可直接调用。
Java 代码 重构 实例 指南 ,欢迎下载
本书基本上是取自”重构”中文版一书的内容,但格式上参照的是chm英文版的格式,还有一些格式小修改,比如第一章的重构前后代码对比。因为时间匆促,个人能力有限,本书难免存在一些缺漏,如果大家发现有问题,随时...
《代码重构》书籍的中文版电子版,软件开发者必读书籍。 重构——改善既有代码的设计(中文版)