不要模拟（ Mock ）不属于你负责的组件！
我们公司正在进行一场关于如何以及在什么地方应该使用 Mock 技术来模拟外部组件（库）的讨论。 一方面，对外部组件的模拟（ Mocks ）让你能够验证系统的边界，而
不要过度依赖于 Mocks！
在为代码编写测试时，通过对代码的依赖关系进行 Mock ，让测试写起来似乎更容易。 然而，过度使用 Mocks 可能带来几个问题： 让测试代码更难以理解。. 与直接使用
代码健康(11)：测试覆盖率的最佳实践
我们一直提倡的是：使用代码覆盖率数据来评估风险，并识别测试与预期的差距。 然而，代码覆盖率的价值是一个备受争议且观点两极分化的话题。每次与一群
测试 UI 逻辑，请使用“正门优先原则”!
针对 UI 逻辑的自动化单元测试，当然是使用“正门优先原则” ，即：尽可能使用 Public 的真实实现代码。 一个对象（ Object ）会有几种接口。例如，它会有一个为大多数
代码健康（10）：包含尊重的CR，才是有用的CR
虽然代码评审被认为是提高软件项目质量的一个有价值的工具。但是，如果反馈评论被认为描述不清晰，或者是过于苛刻，都可能会产生不良后果，如：慢吞吞
代码健康（9）：减少嵌套, 减少复杂性
嵌套过深的代码对可读性有害，而且容易出错。 而通过卫语句来检查某一条件，如果不满足就直接快速失败。 卫语句将计算逻辑与错误逻辑分离。通过消除错误
代码健康（8）：如何让 Code Review 一次性通过？
Code Review 可能让你的代码合入速度变慢，但它也是向其他聪明且有经验的工程师学习改善自己代码质量的机会。 你如何从他们那里获得最大的收获呢？ 目标当然是：
代码健康（7）：注释并不总是好事儿
要写注释，还是不用呢? 当阅读代码时， 没有什么比良好的注释内容更给力的了。 然而， 注释并不总是好事儿。 在哪些情况下，不应该写注释，而是应该重构 假
代码健康（6）：消除 YAGNI 坏味道
消除 YAGNI 坏味道 软件开发的大部分成本是维护成本。减少维护成本的一个方法是：“只在当你真正需要它时，才去编写它”。也就是所谓的 “你不需要它（ You Aren’t Gonna
代码健康（5）：使用较长的命名，也会降低可读性
小心使用过长的命名 创建长标识符很容易被带飞。虽然较长的命名常常让代码更加具有可读性，但是，如果名字过长，也能降低可读性。在GitHub和其它