[查异常网]-20160401-清除代码异味

想下班早的码农都关注我~~~         为什么我们需要有质量的代码？ a)敏捷开发方法是用来应付那些要求代码做大量改动的反馈信息的方法。
b)如果程序没有用一种好的表达方式来表现，那程序会很难读，难维护，难修改。 查异常网 关注了该问题什么是代码异味？ 1k 代码异味是一种由写的很差的代码引起的一种有臭味的感觉，一种程序什么地方会有问题的感觉 20 异味更多的是来自一种直觉，而不是一种有据可查的标准，当你看到有味的代码时你就“感觉”到了 1k 如果你不把异味清除，不久之后你就会习惯这种气味，不再对它有察觉 20 用任何语言都能写出有异味的代码：即使最简单安全的语言，你也能做出天才才能想出的蠢事:) 19 代码异味是一种由写的很差的代码引起的一种有臭味的感觉，一种程序什么地方会有问题的感觉 18 我们经常会意识不到自己在写很臭的代码，经常需要外人为我们指出这点 重复的代码 1:会引起程序里面多个地方相同的错误 2:印度小伙：每两个月我们都会把这相同的错误修改一次 3:Venkat：你们去掉了重复的代码了吗？ 4:印度小伙：你说的这个方法不错！
不必要的复杂 1:程序员本质上讲高兴去处理复杂的问题 2:复杂最恐怖
异常处理 1:问：有什么比一个空的异常捕捉代码更糟糕的？         try{... } catch (Exception e){} 答：一个带有注释的空异常捕捉代码！         try{... } catch (Exception e){// is this required? } 2:Java的异常检查：好还是不好？ 3:如果你不想处理一个异常，就把它传递下去 4:如果你想捕捉两个异常，使用两个catch代码，不要只写一个而用If条件处理
Switch语句& 按类型的条件判断 Switch语句和按类型的条件判断通常可以用多形性来代替
长方法 1:你不能在一屏上看到整个方法 2:这通常意味着一个方法承担这多重任务 3:难于调试 4:不可测试 5:难于重用-> 导致程序员从方法的其它地方拷贝粘贴出重复的代码 6:复杂的条件语句-> 挑战大脑的逻辑分析能力 7:方法长度：组织归纳水平比控制代码行数更重要
方法组成模式 方法里的所有语句都必须处在同一个归纳层次上
无用的注释 1:让代码自我表白 2:标注为什么这样，而不是如何这样 3:对方法表现进行描述等于重复表现 4:这样的注释等于重复写一遍代码     i += 1 //递增 5:长方法里用来描述这个方法有不同的功用的注释     把里面的功能片段提取成小方法& 删除注释 7:IDE排泄物：IDE自动产生的注释空白占位符 糟糕的注释通常产生于TDD*     *(TDD：Threat driven development，恐吓驱动开发)——你应该为方法的表象写注释，你应该为长方法写注释，等 8:产品里的注释： //上帝保佑，我实在不知道这是什么意思
变量名称 1:使用能表意的名称 2:不要用单个字母做名称 3:也不要使用太长的名称
继承 1:继承更多的是被滥用了 2:组合通常优于继承 3:在一对一关系中使用继承，满足Liskov替换原则 4:不要用继承来实现方法重用 5:重用方法时，委托是个更好的选择
粘手的语言1:这种语言更容易导致犯错误
最臭的代码 1:冗长的类 2:重复的代码 3:淘汰的方法 4:不必要的塑型(cast) 5:过度使用设计模式
代码除味 1:代码复查！         写出之后尽快进行         要增量进行         要复查测试用例 2:可使用结对编程         但要保持结对伙伴的经常变动，否则你会习惯你的气味，不再会有察觉         结对伙伴一、两天调换一次

一些设计原则 1:高聚合 2:低耦合 3:Demeter定律 [不要告诉我，我会通知你] 4:Liskov替换原则 5:先让它跑起来，再让它无误，再让它快速 6:开发/闭合原则 7:反向依赖 8:单一责任原则
一些参考书籍 代码整洁之道(Clean Code) 代码大全(Code Complete) 2 程序员修炼之道(The Pragmatic Programmer) 敏捷开发修炼之道(Practices of an Agile Developer) Smalltalk Best Practice Patterns 实现模式(Implementation Patterns) (from @protoiyer) 点击下方“阅读原文”查看更多 ↓↓↓