并发（concurrency）和并行（parallelism）是两个完全不同的概念。

并发，从它的英语本意来看是竞争的意思。这是理解它的关键。没有竞争，并发就无从谈起。为什么会有竞争，那是因为资源是有限的。资源是一方面是有限的，一方面还要满足不同主体的需求，这就会遇到资源的共享。这样以来，就要指定一些规则，让大家有效，并且安全的利用这些资源。这里的并字，强调的是一种秩序。

并行，和竞争没有半毛钱的关系。并行指的是一个任务的属性，看它能不能被化分成相互独立，可以同时完成的小任务。比如说，有一个任务，是要数一本书一共有多少字，那么这个任务就可以被分成很多份，让小明数十页，小微数另外十页。此处的并字，侧重点是指任务能不能可分，能不能同时进行，来达到加速的目的。

两者，不是一个概念，不对立存在。不同的用法是为了达到不同的目的。一个很好的例子，就是JVM中不同的垃圾回收算法，有的是并发的，有的是并行的。

说有模块A，B，C。A依赖B和C，B依赖C。在A的POM中，可以只声明对B的依赖，而省略C。

有人说了，这样做不好，如果有一天B不依赖C了，而A仍然需要C，A就傻逼了，因为他躺着中了一枪。所以有人说，A一定要明确的声明对C的依赖，而不是靠B做一个传递依赖。

我觉得，任何事的对与错都不是绝对的，得看。

如果真的不好，与其保留这种名不正言不顺的做法，不如让Maven直接给它删了，何必模棱两可呢。避免许多口舌。

这里所说的级别是指一个测试所覆盖的系统的范围的大小。一个测试所覆盖的系统越多，它的级别也就应当越高。之所以想谈软件的级别，是因为对测试级别的不合理划分会引发更多的开发成本，降低开发效率。

在软件开发的整个生命周期中，在它的交付阶段，一个必不可少的步骤便是验收测试。验收测试的目的在于证明软件可以满足客户的所有需求。这个测试是软件测试中的最高级别的测试。它的特点有，系统覆盖范围最为全面，从用户界面，到算法逻辑，到数据存储，全部囊括其中。其次，测试必须基于用户的真实使用环境，一切都是真枪实弹，不能参杂任何的仿真的元素。最后，这种测试往往不能被完全自动化，它的执行会牵连到测试人员的直接参与。

从以上特点我们可以总结出来，一个测试的级别越高，它的执行成本就会越高。其中包括，资源环境的配置，人员的直接干预。这也就必然决定了测试的反馈时间延长（比如说配置环境需要半天，测试人员到位需要提前预约）。其次，由于大的覆盖范围，分析问题，鉴定问题的难度也会增加。因此，一个测试的级别越高，它被执行的次数就应该越少，它被执行的时间段就因该越晚。

我并不反对写高级别的测试，但我反对把一个验收测试当作单元测试用。

技术负债是敏捷开发里的一个词汇，讲的是为了快速解决一个问题，不惜代价，写一个解决方案。燃眉之急虽然接了，却使得代码更加混乱，导致下一次回答新需求的时候，难度更大，耗时更长。就是今天欠下的债，总归要还的。

其实这是把软件开发中遇到的问题，用更加简单易懂的方式，说给非技术人员说的。

然而，往往在很多非技术人员的眼里，负债是一件好事情。贷了款是负债了吧，不过这是一种发展投资的方式，反而会有利于企业的发展。

所以与其用这个可能引起歧义的概念来打比方，倒不如，说得更干脆，跟直接一点，有人便提出了的技术安全的概念。

俗话说，一颗老鼠屎坏了一锅汤。在持续集成中那些随机通过的测试，便是那可恶的老鼠屎。把它们称作随机通过的测试，是乐观的说法，其实它们是一些随机失败的测试。之所以说它们坏了一锅汤，是由于它们飘忽不定的特性，使得程序员对持续集成的结果难以做出准确的判断。

为什么这么说呢？假如，你提交了一段代码，结果测试报错了。如果说你的测试是说一不二的测试，那么你提交的代码肯定是破坏了程序的某些功能。唯一的做法，就是亡羊补牢，提交一个纠正的代码，再运行一次持续集成把所有的测试通过了。可如果这些测试不三不四，它们报错了，有时候，什么都不改，重新运行一遍，就又通过了。可有的时候，是真的错了，必需进行改正。这样一来，这持续集成就成了一个鸡肋，食之无味，弃之可惜。

我是一个比较激进的人，遇到这样的情况，对这些老鼠屎绝不姑息，斩钢截铁的把它们从持续集成的任务中剔除出去。只把那些讲信用的测试留下来，这样一来，虽然测试少了，但至少它们可靠。

可那些随即通过的测试，也不能丢掷一旁，不闻不理，要抓紧时间，把它们纠正过来，把它们从新争取成可以依赖的战斗伙伴。

末了，看看Martin用什么手段来解决这些不确定的测试的。

代码审查的时候，我们总会有些争论。痛苦的不是别人的代码写的不好，而是明明知道写的不恰当，却不能有力的说服他，采纳更好的解决方案。

想要说服别人，一定要先说服自己。这是最最重要的一部分。不能过早的下结论。说得太多，却说得不对，久而久之，说出的话，倒出的词，就没什么分量了。所以一定要充足的把握，才可以开始说服别人。

说服别人，也讲究一定的方法方式，不能靠权势，或武力把见解强加与人。

程序，对于一个程序员来说，是他的劳动成果，是他智慧的结晶。如果受到他人的指责，一个程序员的本能反应便是去反驳他人的观点，保护自己的代码。因此，审查别人代码的时候，一定要提建设性的意见，肯定他已写代码的优点，真诚的指出可以改进的地方。相信稍微有点理想的程序员，都希望看到更美的代码。

谈说服力的同时，我觉得谈谈被说服的能力也很重要，一个可以被说服的人，是一个能理性的看待自己劳动成果的人，是一个拿得起放得下的人，是一个开放上进的人。所以受到别人说服的时候，要耐心的听取别人的意见，要有自我否定的魄力。毕竟，代码审查是一个相互的过程，今天审了别人的，明天会被别人审。

两顶帽子，说的是开发软件的时候，对重构和添加新功能这两种不同活动的区分。戴上不同的帽子就意味着要专心致志的做帽子所代表的事情。

重构是在不改变软件功能的情况下对软件内部结构的优化。为了保证重构只是在优化而不会引进新的BUG，重构的先决条件就是：所被优化的模块一定要有测试的保护。重构完毕以后换上另外一顶帽子，增加新功能，如果新的功能导致原有的测试失败，那我们可以确定这是由于所添加的新功能导致的。就像唱歌跳舞需要找到节奏一样，两顶帽子的灵活搭配，才能把代码写的又快又好。

可有很多时候，迫于时间的压力，很多人都不喜欢戴重构的帽子，对代码的重复，架构的死板，能忍则忍，忍了再忍。以为这样可以更快的完成任务，其实不然。一旦有重复代码的出现，就意味着，程序员犯错误的可能性会增加。首先，是因为每次做改动的时候，都要保证所有的重复处都要做出改动。其次，重复的要多，多以后优化的阻力就越大，如此一来，就进入了一个恶性循环，技术负债越来越多。

戴上重构的帽子，有利于改变这个状况。可有的时候，你给客户说，“别急，在增加新功能之前，让我先重构一下”。客户指定不买单，他付钱是为了要新功能的，而不是要你打磨老代码的。这时候唯一可以说服他们的论据，就是什么都不说，给结果就行了，他们指定喜欢又好又快的。所以，重构到底有没有用，一定得能在实际操作中表现出来。

戴好这两顶帽子，BUG会越做要少，新功能会越添越快，代码质量会越来越好。何乐而不为呢，偷着乐吧。