浅谈 Android 开发文化

Posted 2020-06-09

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了浅谈 Android 开发文化相关的知识，希望对你有一定的参考价值。

质量为王

是的，Google 以#执行为王著称，但#质量为王其实是更应该先做到的重要事项。

对质量水平不高的代码进行优化，会造成不成熟的优化，而不成熟的优化也被成为万恶之源（虽然并非绝对，但大多情况下是这样的）。

好消息：像 Square、SoundCloud、Twitter 这样的企业和一些开发者正通过发表演讲、撰写博客，让 android 开发变得更好，感谢他们！此外， Google 似乎终于对提高 Android 应用程序的质量产生兴趣了！近期， Google 参加了 Android 开发峰会（AndroidDevSummit）和一些其他会议，我们看到了一些关于测试的内容，请继续保持！

现在是时候来提高 Android 开发的质量了。

Android 开发文化暨说明文档。

0. Fail fast 机制：尽快宕机，尽早放弃。

为什么这么说呢？— 因为你要在产品到达用户之前找到问题，那么越快、越早的宕机，对你就越有利，其实这也是你该做的。

本文每一项都会遵循这个基本原则。

1. Pull 请求、代码审核和持续集成

项目开发应该在版本控制系统内完成。开发过程应该通过Pull请求（以下全文简称 PRs），并经过代码审核，否则任何代码都不能直接推送到主开发分支上。每次 PR 会应该触发持续集成（以下全文简称 CI）系统，并构建项目。构建应该是可重复的，每一个队伍里的成员都应该可以轻松地构建项目。

Fail early：如果 PR 的构建在 CI 系统中失败了，在修复完成之前，PR 不要进行合并。

2. 代码质量

你的代码应该是坚实的或者结实的。如何做到这一点，完全取决于你自己。代码质量并不只和 MVP/MVVM/MVC 有关，同时也和 App 中每个组件的每一行代码有关。笔者更倾向使用纯函数和不可变对象。

Fail early：不要成为项目中唯一编写可维护的代码的开发者，确保其他成员也可以写高质量的代码（和他们聊天，一起讨论本文即可激励他们！），从而防止审核时出现糟糕的代码。

3. 静态代码/资源分析

静态代码分析让你在进入生产环境之前找到代码中的问题。同时，也对代码审核大有裨益。比如使用 Android Lint、FindBugs、PMD、SonarQube 和 FB Infer 等工具。

Fail early：在 CI 中运行静态分析，安装配置后，如果项目中出现警告（不仅仅是错误信息），尽早放弃项目。

4. 单元测试

是的！是测试没错！单元测试通常会检查某个函数/对象是否正确地完成它的工作。项目里的测试越多，代码覆盖率越高， App 在发布后的性能，会更好更稳定。事实上，单元测试可以发现大多数愚蠢的 bug。当然，如果你的 App 会进行数据处理的话，单元测试还将帮助你保证代码工作正常。

Android 项目单元测试的简易指南

笔者倾向于在 JVM 上运行单元测试，因为它比在设备/模拟器上运行快得多。
Android 的 Gradle 插件可以运行在JVM上的单元测试。只要把测试加至 test/ java_or_other_lang 即可。
你可以从 IDE 运行测试（右键点击测试->运行）或者从 ./gradlew test 终端。
你很快就会发现，如果在 JVM 运行单元测试，Android SDK 的类会被清除，触发他们时会抛出异常。这固然可悲，但是是可修复的。如果需要 Android SDK 类的话，可以在 Robolectric 测试运行器下运行，Robolectric 提供了大部分实现 Android SDK 类的方法。
JUnit 提供了很棒的测试工具和相当不错的 Rules 概念，但是 JUnit 的断言很不好用。 AssertJ 和 Truth 等工具对断言的支持很好，并且可以在 JUnit （或 TestNG/Spock 等）下运行。
如果你需要检查行为和复制某些对象，你可以使用 Mockito 之类的复制库。

TDD 与否，取决于你，但绝对值得一试！

Fail early: 在 CI 中运行单元测试，如果有一些测试失败了，则尽早放弃。

5. 代码覆盖率

一旦开始编写单元测试，你便需要知道代码覆盖率是否足够好。像 Jacoco 这样的工具可以帮助你检查测试程序所走的代码路径。如果你测试的代码表现依赖于条件语句，代码覆盖率就尤为重要，因为你需要确保代码执行中的所有可能都得到检查。

你可以通过apply plugin: ‘jacoco’语句启用 Jacoco。你可以通过jacocoReport Gradle 任务配置哪些类/包应该被检查。

如果覆盖率不够高，配置代码覆盖工具使之放弃构建项目。如果你刚刚开始在一个已存在的项目中使用单元测试，除了非测试类，一旦测试代码可以覆盖这些类，就将它们从排除列表中删除。这个规则可以保证新代码的覆盖率。根据覆盖报告，你可以使用 jacoco-coverage 插件放弃构建。

Fail early：确保在 CI 环境中检查代码覆盖率，如果代码覆盖率不够高，尽早放弃构建。

6. 功能（UI）测试

没错！更多的测试。功能测试会从用户的角度检查 APP 的功能。功能测试启动应用程序后，会验证某些功能，比如在 UI 界面中加载出的数据是否正确显示。QA 团队进行的大部分工作可以通过功能测试达到自动化，但这并不意味着你不需要 QA 团队。

运行功能测试有两种基本的方法，在 Android Instrumentation 或 UIAutomator 里运行。最主要的区别是，在 Android Instrumentation 里运行功能测试时只能与应用程序交互，并可以接触到程序代码。在 UIAutomator 里进行的测试会运行在系统进程中，并通过Accessibility API（相比于 Android Intrumentation，此方式的功能十分有限）和应用程序进行交互。如果你需要进行应用程序和其他应用间的交互测试 — 可以使用 UIAutomater。但是通常情况下，你可以通过 Android Instrmentation 模拟这类交互并进行测试，而且这种测试无需依赖外部因素。

建议：