soc*_*soc 7 java legacy collections refactoring
当我收到我之前没有见过的代码将它重构为一些理智的状态时,我通常会修复"化妆品"的东西(比如转换StringTokenizers为String#split(),用更新的集合替换1.2之前的集合,制作字段final,将C风格的数组转换为Java风格)数组,...)在阅读源代码时我必须熟悉.
是否有很多人使用这种策略(也许这是某种"最佳实践"我不知道？)或者这被认为是太危险了,如果不是绝对必要的话通常不会触及旧代码？或者将"化妆品清理"步骤与更具侵入性的"一般重构"步骤结合起来更常见？
在进行"化妆品清理"(与更具侵入性的变化进行重构)时,常见的"低悬的果实"是什么？
在我看来,"化妆品清理" 是 "一般的重构".您只需更改代码,使其更易于理解,而无需更改其行为.
我总是先通过攻击微小的变化来重构.您可以更快地编写代码,以后更容易进行结构更改 - 特别是因为它可以帮助您查找重复的代码等.
我通常首先查看经常使用的代码,然后需要经常更改.(这在最短的时间内影响最大......)变量命名可能是最容易和最安全的"低悬的果实",首先是攻击,然后是框架更新(集合更改,更新方法等).一旦完成这些,分解大型方法通常是我的下一步,其次是其他典型的重构.
| 归档时间： |
|
| 查看次数： |
686 次 |
| 最近记录： |