方法组成模式

• 方法里的所有语句都必须处在同一个归纳层次上

无用的注释

• 让代码自我表白
• 标注为什么这样，而不是如何这样
• 对方法表现进行描述等于重复表现
• 这样的注释等于重复写一遍代码

  • i += 1 // 递增

• 长方法里用来描述这个方法有不同的功用的注释
  • 把里面的功能片段提取成小方法 & 删除注释
• IDE排泄物：IDE自动产生的注释空白占位符
• 糟糕的注释通常产生于TDD*
  • * (TDD：Threat driven development，恐吓驱动开发)—— 你应该为方法的表象写注释，你应该为长方法写注释，等
• 产品里的注释：

  • // 上帝保佑，我实在不知道这是什么意思

变量名称

• 使用能表意的名称
• 不要用单个字母做名称
• 也不要使用太长的名称

继承

• 继承更多的是被滥用了
• 组合通常优于继承
• 在一对一关系中使用继承，满足Liskov替换原则
• 不要用继承来实现方法重用
• 重用方法时，委托是个更好的选择

粘手的语言

• 这种语言更容易导致犯错误

最臭的代码

• 冗长的类
• 重复的代码
• 淘汰的方法
• 不必要的塑型(cast)
• 过度使用设计模式

代码除味

• 代码复查！
  • 写出之后尽快进行
  • 要增量进行
  • 要复查测试用例
• 可使用结对编程
• 但要保持结对伙伴的经常变动，否则你会习惯你的气味，不再会有察觉
• 结对伙伴一、两天调换一

一些设计原则

• 高聚合
• 低耦合
• Demeter定律 [不要告诉我，我会通知你]
• Liskov替换原则
• 先让它跑起来，再让它无误，再让它快速
• 开发/闭合原则
• 反向依赖
• 单一责任原则

一些参考书籍

• 代码整洁之道(Clean Code)
• 代码大全(Code Complete) 2
• 程序员修炼之道(The Pragmatic Programmer)
• 敏捷开发修炼之道(Practices of an Agile Developer)
• Smalltalk Best Practice Patterns
• 实现模式(Implementation Patterns) (from @protoiyer)

问和答

• 关于使用代码检测工具，例如PMD：这样的工具非常的有用，它能让你捕捉到很直接的问题，使你的代码复查工作专注于高层面的设计原则问题
• 关于IDE上附加的工具：不要自己去运行它们。让这些工具在后台自动的运行(或智能化)
• 动态语言里需要重构吗：动态语言里没有太多的自动重构工具，但程序员仍然应该手动的重构
• 关于动态语言的设计模式：每种语言都有自己的模式和特色。例如：smalltalk的execute around method模式
• 关于掌握多种语言
  • 你应该知道处理一个问题的多种范式，多种风格和多种方式
  • 一种语言中学到的特色方法应用到其它语言里
  • 知道各种不同方式的各自风险
• 关于编程语言趋势：对函数性编程，移动设备编程兴趣浓厚
• 关于著书：长时间的思考书中的各项主题，多做这方面话题的讨论，吸取精华。当开始动手去写时，已经胸有成竹，2周内把书写成
• 关于思考文献：思考文献很有用，但你也要多看看批评性的思考性文章，它们是关于你如何去思考的(double loop learning?)
• 关于学习：在用户组里跟其它人合作，交流，讨论。你并不能学到所有的东西，但要努力缩小自己的“你不知道你不知道的东西”，让它成为“你知道你不知道的”

原文：http://www.aqee.net/2011/05/18/cleaning-up-code-smells/

本文链接：http://www.blueidea.com/tech/program/2011/8454.asp　

出处：外刊IT评论
责任编辑：bluehearts

上一页 清除代码异味 [1] 下一页

◎进入论坛网络编程版块参加讨论