重构

按有用程度 按页码先后 最新笔记

• 

  第三章 代码的坏味道

  tokyo

  没有任何度量比得上见识广博者的直觉。 在我看来，一篇好文章应该是简单、形象、易懂的。 再次意识到，设计模式使用方面的确是很多的！ 阅读介绍经验的书籍时，你如果有足够的经验，那么会引起共鸣，也会有更好的理解。 利用“臭味”条款来选择对应的方法。观察重要的特征。 # 重复的代码。尽可能减少。 类中的重复方法合并； 子类互相重复的方法提炼为父类的方法（我认为还得看方法的重要程度，要是一千个子类中两个子类.. (更多)

  没有任何度量比得上见识广博者的直觉。

  在我看来，一篇好文章应该是简单、形象、易懂的。

  再次意识到，设计模式使用方面的确是很多的！

  阅读介绍经验的书籍时，你如果有足够的经验，那么会引起共鸣，也会有更好的理解。

  利用“臭味”条款来选择对应的方法。观察重要的特征。

  # 重复的代码。尽可能减少。

  类中的重复方法合并；

  子类互相重复的方法提炼为父类的方法（我认为还得看方法的重要程度，要是一千个子类中两个子类重复了，那么不应该提炼到父类中）；

  类似的方法提炼出相同部分的子过程；

  不同的算法做同样的事情，利用简单的、清晰的替换掉另外一个。

  两个无关类有相同过程，则应该看情况决定是否应该提炼出第三个类。

  # 过长函数。拥有短函数的对象会活的比较长。

  程序愈长愈难理解。

  当我们感觉应该给一个函数加注释的时候，我们就应该把这部分提炼成独立函数，并以用途命名，（简单易懂，我喜欢），哪怕替换后的函数调用比函数体还长，只要能够说清楚干了什么，也值得这样做。

  如果参数太多，那么应该利用查询代替参数，亦或是直接重写函数。

  注释、条件、循环都是提炼的信号。

  # 过大的类。

  变量过多。。方法过多。。

  提炼方法，消除过多代码。

  # 过长参数列。

  用方法替换参数，请求数据。

  # 发散式变化。一个类对应多种变化，则应该分裂类。

  针对某一外界变化的相应修改，都应该只发生在一个类中！？？？

  # 霰弹式修改。一个变化对应多个类，则应该合并。

  把所有需要修改的代码移动到同一个类中。

  # 依恋情节。

  函数应该放在它依赖最多数据的那个对象。

  # 数据泥团

  用新类代替重复出现的数据？

  # #

  面向对象，少用switch。因为switch重复，多态可以带来更好的解决……

  # 平行继承体系。消除这种依赖，利用引用？

  #……

  消除冗余的类；删掉不用的功能；不用为将来打算太多？

  把临时变量提炼到method object中；过度耦合；利用继承消除过多的中间代理；消除过度亲密的类，用代理代替继承；合并异曲同工的类？；弥补不完美的类库；封装数据类。

  # 如果要注释代码，那么提炼方法；如果要注释方法，那么重新命名方法；如果需要注释说明规格，那么用断言。

  想写注释时，先重构。

  当不知道做什么的时候，才是注释的良机，你可以记录下你的想法，你将来想干什么？ (收起)

  2011-09-02 14:28:12   1人收藏   回应

  收藏

  推荐
• 

  第52页

  小刀

  测试对重构至关重要，是保证程序不因重构引入bug的前提。 基于pojo的编程比较清晰，但是需要大量的处理器等类来加工/处理，都使用这种方法会不会导致程序更加面向过程？缺少面向对象的感觉。 好像有人认为大量以er结尾的类，会导致软件去对象化。大致是这个意思，具体怎么说的不记得了。 (更多)

  测试对重构至关重要，是保证程序不因重构引入bug的前提。

  基于pojo的编程比较清晰，但是需要大量的处理器等类来加工/处理，都使用这种方法会不会导致程序更加面向过程？缺少面向对象的感觉。

  好像有人认为大量以er结尾的类，会导致软件去对象化。大致是这个意思，具体怎么说的不记得了。 (收起)

  2012-01-15 23:21:55   回应

  收藏

  推荐
• 

  第15页

  码蜂 (反者道之动)

  任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。 使用更加表意的变量名、函数名、类名等等，都是增加代码清晰度，提高代码表达力的最简单、直接的手段。代码是写给人看的，永远不要怀疑这样小的修改是否值得或是否有必要。 thisAmout -> result each -> aRental (更多)

  任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。

  使用更加表意的变量名、函数名、类名等等，都是增加代码清晰度，提高代码表达力的最简单、直接的手段。代码是写给人看的，永远不要怀疑这样小的修改是否值得或是否有必要。

  thisAmout -> result

  each -> aRental (收起)

  2011-12-01 14:51:59   回应

  收藏

  推荐

• 

  第1页

  麻匪

  我只是想知道，笔记出现在哪里？ (更多)

  我只是想知道，笔记出现在哪里？ (收起)

  2011-02-20 11:16:45   回应

  收藏

  推荐
• 

  第1页

  麻匪

  相同页的笔记会合并吗？ (更多)

  相同页的笔记会合并吗？ (收起)

  2011-02-20 11:17:27   回应

  收藏

  推荐
• 

  第1页

  zhangyou1010 (关注豆瓣)

  跟代码大全有很多相似的内容 (更多)

  跟代码大全有很多相似的内容 (收起)

  2011-04-20 08:30:55   回应

  收藏

  推荐

• 

  第52页

  小刀

  测试对重构至关重要，是保证程序不因重构引入bug的前提。 基于pojo的编程比较清晰，但是需要大量的处理器等类来加工/处理，都使用这种方法会不会导致程序更加面向过程？缺少面向对象的感觉。 好像有人认为大量以er结尾的类，会导致软件去对象化。大致是这个意思，具体怎么说的不记得了。 (更多)

  测试对重构至关重要，是保证程序不因重构引入bug的前提。

  基于pojo的编程比较清晰，但是需要大量的处理器等类来加工/处理，都使用这种方法会不会导致程序更加面向过程？缺少面向对象的感觉。

  好像有人认为大量以er结尾的类，会导致软件去对象化。大致是这个意思，具体怎么说的不记得了。 (收起)

  2012-01-15 23:21:55   回应

  收藏

  推荐
• 

  第15页

  码蜂 (反者道之动)

  任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。 使用更加表意的变量名、函数名、类名等等，都是增加代码清晰度，提高代码表达力的最简单、直接的手段。代码是写给人看的，永远不要怀疑这样小的修改是否值得或是否有必要。 thisAmout -> result each -> aRental (更多)

  任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。

  使用更加表意的变量名、函数名、类名等等，都是增加代码清晰度，提高代码表达力的最简单、直接的手段。代码是写给人看的，永远不要怀疑这样小的修改是否值得或是否有必要。

  thisAmout -> result

  each -> aRental (收起)

  2011-12-01 14:51:59   回应

  收藏

  推荐
• 

  第13页

  码蜂 (反者道之动)

  重构技术系以微小的步伐修改程序。如果你犯下错误，很容易便可发现他。 要有测试，测试要self-checking，频繁运行。 (更多)

  重构技术系以微小的步伐修改程序。如果你犯下错误，很容易便可发现他。

  要有测试，测试要self-checking，频繁运行。 (收起)

  2011-12-01 14:49:17   回应

  收藏

  推荐