测试 UI 逻辑，请使用“正门优先原则”!
针对 UI 逻辑的自动化单元测试，当然是使用“正门优先原则” ，即：尽可能使用 Public 的真实实现代码。 一个对象（ Object ）会有几种接口。例如，它会有一个为大多数
代码健康（10）：包含尊重的CR，才是有用的CR
虽然代码评审被认为是提高软件项目质量的一个有价值的工具。但是，如果反馈评论被认为描述不清晰，或者是过于苛刻，都可能会产生不良后果，如：慢吞吞
代码健康（9）：减少嵌套, 减少复杂性
嵌套过深的代码对可读性有害，而且容易出错。 而通过卫语句来检查某一条件，如果不满足就直接快速失败。 卫语句将计算逻辑与错误逻辑分离。通过消除错误
如何让 CodeReview 一次性通过？
Code Review 可能让你的代码合入速度变慢，但它也是向其他聪明且有经验的工程师学习改善自己代码质量的机会。 你如何从他们那里获得最大的收获呢？ 目标当然是：
消除 YAGNI 坏味道
消除 YAGNI 坏味道 软件开发的大部分成本是维护成本。减少维护成本的一个方法是：“只在当你真正需要它时，才去编写它”。也就是所谓的 “你不需要它（ You Aren’t Gonna
使用较长的命名，也会降低可读性
小心使用过长的命名 创建长标识符很容易被带飞。虽然较长的命名常常让代码更加具有可读性，但是，如果名字过长，也能降低可读性。在GitHub和其它
如何做到高效的Code Review
Code Review 一直是软件工程中的一个好实践。本文仅简单阐述 Code Review 对工程团队的重大意义，以及高效 Code Review 的必要实践。 主要内容包括： Code Review 对工程组织的意义 提交者应
不要痴迷于原始类型
不要痴迷于原始类型 编程语言提供基本类型，如 int ，string 和 map ，这些类型在许多场景下都被用到，例如，利用 string 保存人名，或者网页URL等等。 然而
代码健康（2）：接口设计，要让其很难被误用
这是《Effective C++》中的第18条原则。 我们都在试图避免代码中的错误。 那么，如何避免调用者以错误的方式调用了你的这些代码呢？ 让你接
谷歌pH值：衡量软件产品的项目健康度
最近，我又读了一遍《 SRE Workbook 》，其中又一次强化我的印象的一点是：SRE 是从用户视角为出发点，来识别和设计 SLO 的。由于这些已经上线的产品已经为真实用