【IT168 技术】本文献给那些无经验无意识的年轻编程菜鸟和那些人老珠黄却又投身IT致力于信息产业繁荣的程序员们。
最近， 我和很多工程师在一个很平常的伦敦码农之夜讨论了一下怎么我们要培训新入行的那些菜鸟这么多东西。有人要知道一个大学毕业生如何进行单元测试，有人要跟他们解释为什么依赖注入比以来查询要好。于是我思考了一下走过的人生，简单扼要的解释了一下我们为什么要进行单元测试和我们为什么需要它们。
YAGNI
你根本不需要它 —— 这里的问题是，人们往往写了远多于解决问题或者实现程序功能所需的代码。一种典型的情况：在Java EE的session beans中加入根本不需要的finder方法。
DRY
不要写重复的代码——在方法、类、包和包对象中大量重复地编写代码。一种典型的情况：在单元测试中复制和粘贴代码，在实体和前端重复元数据。
KISS - Keep it Simple Silly (or Stupid)
保持简单(或者愚蠢)，是一句高级程序员间的口头禅。只针对需要解决的问题码字而不是写稍微复杂一点的代码。 同理见 奥卡姆的剃刀 (如无必要，勿增实体)。
常见错误： 程序中含有过多的抽象层
WET - Write Every Time
每次重写 —— 避免重复的反模式， 当代码被有意识的在不同的包，类或者函数中重写一次又一次。
症状: 决定用自己的方式做一件事，来代替和其它的开发者合作，并且发现大家做的事情有许多共同点。
典型的解决方法： DRY(避免重复原则)单元测试 和重构
WETTT
将一切写上一万遍——WET的夸张的通俗版本
R3
三的规则——这不是一个与R3同名的专有操作系统，或者经典的80年代的电子游戏，或者一款大众高尔夫的极限改装车; 但是这个想法当你的代码在一个方法、函数或类中有三个重复的部分时，那么你就需要把这些重复的部分重构到一个方法里。 与 DRY 和WET原则相关。
典型症候：因为时间的压力而忽略重复代码，或者团队管理者说我们不需要在这个阶段重构
DBC(契约式设计)
契约式设计 - 它的核心思想是在建立一个服务之前，首先定义出正式的、精确的、可验证的接口. 用Java写一个接口，然后可以很容易的围绕这个接口来编写实现类;由于一个接口可以有不同的实现类，所以，接口可以使你的架构得到高内聚、低耦合的效果(译注：java中的接口就是契约).经典例子：JDBC规范从1.0版本以来，有很多不同的关系数据库的实现，包括：MySQL,Postgres, H2, Derby等。每一个Java程序员都知道如何对JDBC进行编码，因为他们没有与一个不同的实现作战，因为DBC已经保证了它在大部分时间都会做正确的事。
同样与之相关的是标准的应用程序接口。
