【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已经保证了它在大部分时间都会做正确的事。

　　同样与之相关的是标准的应用程序接口。

　　BDUF or BUDF

　　大型的软件前端设计，对于企事业厂家来说，存在一个问题;比如：有时候需要一百到一千页程序文件，这些软件项目开发已经通过了涉及项目不深的架构师和业务分析师需求，他们花了几个星期调查投入和对文档的要求业务进行聊天洽谈，但是仅仅得到一个结果，这些文件实际上一无所值。

　　解毒剂：技术领先和一些重要的架构师与分析师和顾客洽谈的项目开发人员，大家会话思考;

　　症状：瀑布开发方法和投资银行it文化要求方面;

　　解毒剂：未知，许多人企图把”agile“用一个大A和小A到企事业厂家多多少少取得了一些成功，但同样也面临着一些失败。

　　红皮书

　　介绍了极限编程这本书，它有着粉红色的封面，由Ron Hendries所写，由于这本书是2000年出版的，已经相当旧，除非仅作参考，并不推荐给初学者来阅读，还有其他近期的关于敏捷开发的书籍和课程帮助新的Java开发者。

　　YOLO

　　只加载一次(如果有的话) - 这与你要在一个应用系统中有一个单一正确的来源有关。这是MIS架构问题，如果某人通过enoughClass例并没有想到这样的功能需求：购物车服务EJB - 你只需要在应用程序中实现出一个支付点，即使你有很多支付点提供者(信用卡和借记卡，第三方和PayPal)。如果是这样最好把YOLO(You Only Load It Once)和 YAGNI(You ain't gonna need it)加在一起使用。你不确定系统其它的部分会不会加载数据，因此你要把数据在模块里(你可以通过YOLOIF(You Only Load It Once If Ever)的方式保存一个日志客户端，这样一个功能在12或18月没人再用过的时候，你就可以把它很容易的丢弃掉)。

　　题外话：如果你发现数据不断通过Web请求上传，这可能是真需要缓存而不是YOLO了。

　　Spike

　　使用敏捷开发，是一种快速的编写代码的方法。在开发的时候，你经常会去找新的API，像云服务，或者是像JavaFX那样的用户API接口，又或者去找一些新的API，以便可以比较好的实现代码的函数。简而言之，在完全投入之前，你要努力的建立一些信心并准备一些其他资源。Spikes 通常包含这样的问题，保持工作的流程的最短路径和受限于时间长度。这是很聪明的啦。

　　典型的例子：采用一种构建系统–从apache ant 到Maven;从Subversion到的Git;采用新的开放源代码库。

　　TDD

　　测试驱动开发-因为没被完整解释为一种操行及思想的改变，所以经常会矛盾。“你永远只会做4件事的其中一件：写单元测试，写产品代码，重构单元测试，重构产品代码;而且这些事永远不要同时做超过一件以上。“

　　TFD(测试先行开发)

　　测试先行开发 - 是建立在TDD(译注：测试驱动开发)思想上的，核心思想是在编写任何产品代码之前首先编写单元测试代码. 一旦你完成了一个新的单元测试，你将能够确认这个单元测试是否失败，如果没有失败可以将其整合到产品代码中。之后运行所有的单元测试直到你得到了绿色状态条(译注：junit中，如果测试通过的话，将用绿色状态条进行展示;如果没有通过则用红色状态条展示)。以上是一个迭代过程，用来保证你的产品代码全部通过验证。

　　Velocity

　　Velocity是一个非常基础的SCRUM(敏捷软件开发)的ROI(投资回报率)度量标准，它和财务预算、报表没有任何关系。Velocity仅仅表示每一个团队每一次迭代所产生的故事点的数量。

　　对于SCRUM的经验来就看，Velocity等价于在一段由很多个时间间隔聚合而成的时间里所完成的工作的单元聚合(也就是在一段时间内可以完成多少工作Velocity = work / time)，并在两个或更多个冲刺过程中指导你来度量任务的每个阶段。

　　需求功能点

　　对于每一个任务或者迭代中的用户需求, 很难预测有多难去实现来给大家提供一个参考. 需求点经常写成斐波那契数列的形式: 0, 1, 1, 3, 5, 8, 13, 21, 34, 55, 89, 144。在世界上的每一个敏捷团队都有一个用户需求点的定义。

　　团队通过积压的工作来预测决定，每个团队成员来决定哪些该在下一个迭代完成。

　　DTSTTCPW

　　做最简单可行的工作 – 它与Spike和Kiss密切相关.如果你是一家投资银行的交易系统开发者，在时间紧迫的情况下.正确的做法是与其他团队成员协作及有效沟通, 否则你将是自找麻烦。(译注：做最简单可行的事已经充分解释了它的本意)

　　VoC(客户的声音)

　　客户的声音 - 这是一个SCRUM方法论中的一个术语, 真实的客户80%的时间里意味着他是一个代理人或占位者，另外20%我不确定,客户才是最理解业务需求的那个人.有些人喜欢将这个缩写称作理智的声音，尤其是他们不喜欢直接与客户打交道。(译注：我实在不理解原作者想要说什么，其实VoC的含义就是真正的业务需求来自于我们的客户、用户，只有他们才是最权威的，所以要多与客户进行沟通，已获得最直接、有效地需求)

　　单元测试

　　在Java编程语言中，单元测试是Junit框架或TestNG框架中的一个测试类，专门用来验证应用中某个单独函数是否有效。单元测试需要一个目标，这个目标可以是一个Java类，服务Bean,托管Bean或是一些功能的实现类.单元测试经常被看做是一个快速和有效的测试手段。

　　功能测试

　　功能测试是一个更大的考验，它同样也是一个单元测试，被设计用于测试类包或整个应用基础设施的子部分。功能测试主要是用来验证应用程序是否满足了客户对性能、结果和有效性的需求，Symptom: 功能测试不一定是一个单元测试，另外，并非所有的功能测试是一个验收测试

　　验收测试

　　验收测试名义上与功能测试相同.验收测试是指客户希望看到他们所签署的功能实现(译注：需求)全部通过验证。Symptom: 如果客户在演示过程中(译注：验收过程中)对应用程序不满意的话，将会终止本次验收测试，待解决后再进行下一次验收。

　　SOLID

　　一组五项原则：单一职责原则，开闭原则，里氏代换原则，接口隔离原则，依赖倒转原则。

　　简单责任原则

　　一个对象类，一个服务数据封装类，一个网络服务，一个函数或过程应该只有一个单一的责任。

　　症候：很难为复杂的类写单元测试， 因为它可能需要做上千次的重复。

　　开闭原则 Open Closed Principle

　　接受扩展，但是不接受修改。意思是你可以拥有子类的对象，但是这个对象是被封装的，不允许外部对象通过对封装的内部进行改动。

　　症状：对象实现的溢出，硬编码以来， 和不是面向java接口的编程(或者接口像构造器 比如 Scala 特性和混合)。

　　Liskov Substitution Principle(里氏代换原则)

　　具有交换能力的思路，表示成DBC(契约式设计)。

　　对象X是T的实现类，那么我能够用对象X来代换T。

　　这是一个基本模拟对象，模拟实现一个框架，做一般性测试;代理远程对象，可持久化对象;应用服务器和生命周期监控;即插即用且可重新开始的应用,我能继续，但我不会;

　　(译注：原文简直是不知道作者想要说什么，下边给出更容易理解的LSP解释：里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。)

　　ISP:接口隔离原则

　　对一个服务接口来说，实现一个功能比实现一堆功能要好.Symptom: 未能遵循KISS(译注：保持简单)原则. 过去，在非标准C++字符串库里，每个人都想向其中扔一些操纵C/C++ String(char*)的方法。

　　依赖倒转原则

　　即不要在两个有直接关系且相互依赖的对象之间硬编码。比如在Java EE环境中，你就需要使用一个依赖注入容器(比如CDI)来注入不同的托管Bean到某个服务Bean之中。依笔者浅见，依赖倒转还有另一层含义，为服务或Java Bean提供了一种生命周期管理机制。它们的生命周期被应用户服务容器、云平台供应商或者其它您正在用的其它类似的东东所管理。

　　还有另一种学院路线的想法：每一个应用(的生命周期)都将是受控的是一种趋势和努力方向，不管是操作系统、虚拟机、WEB容器或者时下流行的移动平台(iOS和安卓)。

　　设计模式

　　Erich Gamma等人写过一本经典的关于设计模式的书，向你的技术负责人去借这本书;如果她/他没有这本书，我只能说这真的很烂。问他们要一笔培训预算，然后自己去买一本。