冯小卫

// 什么时候执行重构——代码的坏味道 // 1.重复的代码 // 2.过长的方法（当一段代码你觉得别人看起来困难，你可能需要添加注释的时候，其实你可以抽取成一个方法，然后标注一个优雅的方法名） // 3.庞大的类（很有可能职责过多，职责单一是一种很好的设计） // 4.过长的参数列表（让使用者很疲惫） // 5.发散式变化（添加一个功能，可能引起多处变化

// 复制，粘贴给程序带来维护上的巨大挑战，一段相同的代码，绝对不应该出现在不同的两个地方。当然，你可以这样做，但是这种代码一旦出现问题，你会记得要修改几个地方吗？    // 如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。千万不要说有时间再做重构，有时间再做等于永远不会做（可以自己分析一下，首先，公司明

// 在对象之间搬移特性 // 1.在程序中，有个方法与其本类之外的另一个类进行更多的交流，这个时候在该方法最常引用的类中建立一个有着类似行为的新方法，把旧方法变成一个委托函数，或者是直接移除。这有助于隔离变化。 // 2.移动实例变量可以参考第一点 // 3.搬动一个方法或者属性之前，先注释它，可以瞬间看出一些东西。 // 4.当一个类做了应该由两个类做的事情，那么，就提炼一个新

我从不一开始就想写下完美的代码，我想也没有人能办到。我只是不停的雕琢它们，直到我认为完美…… 命名： 1.名副其实，从名称上看出用途，如果需要注释来表达用途，你已经输了…… 2.具有前缀（后缀）的命名方式是上世纪的产品，以后就忘记吧…… 3.包的命名规范：域名+项目名+模块名/层名 4.类的命名规范：类的名字必须由大写字母开头，一个单词中的

代码是程序员的一切，让我们快乐，让我们忧愁。看着优雅的代码，赏心悦目，看到恶心的代码，痛苦不堪。那么，是什么让代码变得恶心呢？          网上有如下解释：架构不合理，需求变更，进度压力…… 首先，我觉得任何架构都是合理的，也都是不合理的。一个基本架构，能够完成现有的功能，效率上也说得过去，那么，它就是一个合理的架构。任何一个架构，都会不断的经受需求变更的挑战，没有任何人可以一开始