剡溪
本文的目的长久以来,码农们有一种默契的共识,只有写的好的代码才能写单测,代码的可测性也因此成为了评判好代码的一个标准。但是,同学有没有想过,我们手里有多少是写的好的代码,很多情况下,我们接手的代码都是又长又臭的“面条代码”,难道我们就不能对这些应用写单测了吗?难道这些应用不是更需要单测的保障吗?在本文中,我将使用一种全新的单测解决方案,通过这个方案,再复杂的应用也能简单的实现单测覆盖,保障我们的业
本文是“面条代码系列”文章的第一篇,在这个系列里,我将从理论开始,再通过实践和大家一起来探讨如何才能写好代码。 [如何才能不写出面条代码--理论篇](???) 如何才能不写出面条代码--物流计费引擎实践 如何才能不写出面条代码--物流计费清洗管道实践 如何才能不写出面条代码--物流计费分摊实践 ## 面条代码系列文章目的 一直以来有一个问题困扰着我,大家好像都在不断的批判面条代码,但不知不觉中,每
## 本文的目的 单元测试无疑是软件开发中特别重要的一个环节,只有有了单元测试,你的代码才有可能具备可重构的能力。本文主要讲述单元测试中如何解决数据库的问题。 ## 问题 有人可能存在疑问,为什么单元测试需要用到数据库呢?随着软件的复杂程度不断的增加,针对某个类或方法的测试已经远远无法满足我们的需求。我们需要有一种更加高效,投入产出比更高的测试方式,我们称之为组件测试。而组件测试是需要用到数据库
### 前言 关于贫血模型与充血模型,已经有大量的文章写到了,但大部分都只是写了两种模型的对比,其中的例子也相对比较简单。 当我们真正在使用充血模型的过程中,还会碰到很多问题,本文期望通过我们复杂的业务场景,深入的讲解我们在真正使用充血模型时,到底会碰到哪些问题,我们又要如何来解决。 ### 什么是充血模型 Martin Fowler在2003年发表的一篇文章中,第一次提出贫血模型的概念,他把贫