codeek

相关坑的分享 https://lambeta.com/2016/05/24/Using-Java1.8-to-Target-Older-JVMs/

怒点赞。哪都能看到群主宣传 FP ，好样的！

之前听过几期，包括了红烧 Lo 姐的 Clojure 专访以及 haskell 语言分析，确实是难得的好节目。

正则表达式默认是贪婪匹配(最长匹配)，*？就开启了最短匹配，这里，也就是 0 个 b 了。

单元测试最好的入门方式是 TDD (Test Driven Development)，即测试驱动开发。简单来讲，就是先写测试，后写实现代码。

TDD 不是什么高深的概念，只是一种 Agile 的实践方式。很多人习惯先写实现代码，后“加测试”的编码方式，原因有二，一是实现代码还没有，不知道对哪个方法进行测试；二是懒，觉得测试是额外的工作负担，不到万不得已（比如：项目组强制）不会写测试，即使写也就挑几个好弄的方法，加一个正常流的测试。

这样的写法很容易导致几个问题：
1. 实现代码耦合，不便测试；
2. 实现代码过度设计，类文件剧增，代码量一多，维护性绝对不好；
3. 测试覆盖率很低，单元测试是拿来忽悠领导的，跟质量无关。

楼主说自己无从下手，估计是用了“加测试”的方式。如果是这样，那么 refactor （重构） 是你该先学的技能。设计良好的代码，接口很清晰，耦合度低（比如：楼上提到的 DI [依赖注入] ），一般写单元测试非常容易。

TDD 具体的实践方式，这里我暂按不表，网上的教程多如牛毛。其实它的核心理念就是让你知道如何从需求出发，拆接出任务（ tasking ），按照任务一条条来写完测试。然后按照测试->实现->重构（红->绿->黄）的圈完善所有的功能。坚持这样，功能就从需求逐步演化成可维护的代码了。

effective java

你可以从这个角度来学习 maven 或者 gradle: 如何在命令行中用一条命令完成编译，单元测试，打包，集成测试，部署这些任务。简单点，就是自动化。

成都联通还没收到