硅谷大厂

代码健康(11):测试覆盖率的最佳实践

我们一直提倡的是:使用代码覆盖率数据来评估风险,并识别测试与预期的差距。 然而,代码覆盖率的价值是一个备受争议且观点两极分化的话题。每次与一群

继续阅读

测试 UI 逻辑,请使用“正门优先原则”!

针对 UI 逻辑的自动化单元测试,当然是使用“正门优先原则” ,即:尽可能使用 Public 的真实实现代码。 一个对象( Object )会有几种接口。例如,它会有一个为大多数

继续阅读

代码健康(10):包含尊重的CR,才是有用的CR

虽然代码评审被认为是提高软件项目质量的一个有价值的工具。但是,如果反馈评论被认为描述不清晰,或者是过于苛刻,都可能会产生不良后果,如:慢吞吞

继续阅读

代码健康(9):减少嵌套, 减少复杂性

嵌套过深的代码对可读性有害,而且容易出错。 而通过卫语句来检查某一条件,如果不满足就直接快速失败。 卫语句将计算逻辑与错误逻辑分离。通过消除错误

继续阅读

代码健康(8):如何让 Code Review 一次性通过?

Code Review 可能让你的代码合入速度变慢,但它也是向其他聪明且有经验的工程师学习改善自己代码质量的机会。 你如何从他们那里获得最大的收获呢? 目标当然是:

继续阅读

代码健康(7):注释并不总是好事儿

要写注释,还是不用呢? 当阅读代码时, 没有什么比良好的注释内容更给力的了。 然而, 注释并不总是好事儿。 在哪些情况下,不应该写注释,而是应该重构 假

继续阅读

代码健康(6):消除 YAGNI 坏味道

消除 YAGNI 坏味道 软件开发的大部分成本是维护成本。减少维护成本的一个方法是:“只在当你真正需要它时,才去编写它”。也就是所谓的 “你不需要它( You Aren’t Gonna

继续阅读

代码健康(5):使用较长的命名,也会降低可读性

小心使用过长的命名 创建长标识符很容易被带飞。虽然较长的命名常常让代码更加具有可读性,但是,如果名字过长,也能降低可读性。在GitHub和其它

继续阅读

代码健康(4):使用较长的命名,也可能降低可读性

利用“ commit message ”和“ issue ”提供上下文 阅读其他工程师的代码有时会感觉像是在考古,其中可能充满了难以破译的,奇怪(甚至令人瞠目结舌)的描述。**写代码

继续阅读

如何做到高效的Code Review

Code Review 一直是软件工程中的一个好实践。本文仅简单阐述 Code Review 对工程团队的重大意义,以及高效 Code Review 的必要实践。 主要内容包括: Code Review 对工程组织的意义 提交者应

继续阅读