构建可维护的 Android 应用程序

为什么即使一切正常，你也应该关注可维护性？用原型尝试新事物来提升知识并非坏事，但当你开始构建将被使用多年且规模越来越大、越来越复杂的应用程序时，你必须确保能够持续添加功能而不会遇到问题。当许多人每天都需要你的软件来完成工作时，你不能构建一个会在自身重量下崩溃的东西。因此，这里有一些指导原则可以帮助你。

保持代码整洁并编写文档

当你需要定期返回修改旧代码时，清晰的名称和文档非常宝贵。你只编写一次代码，但会多次阅读它，因此你应该尽可能简化这项工作。一致的编码规范也有助于提高可读性：阅读代码风格跳跃的代码令人不快，你应该专注于代码本身，而不是它的外观。

此外，我不相信所有代码都可以做到自文档化。这是一个值得追求的目标，但有时你必须进行一些不太干净的hack：当你几年后再次尝试理解它时，一些解释会大有帮助。在其他情况下，例如当你实现复杂的业务逻辑时，如果代码行为异常或逻辑需要更改，你需要知道代码的预期作用。

能简单就别复杂

遵循良好的敏捷原则，你不想在开始之前就计划应用程序中将要发生的一切。别误会我的意思，你应该对你的目标有一个大致的概念，并规划出一个基本的架构，但要尽可能保持简单，同时保持条理。你可以根据需要重构复杂的代码以添加更多抽象层，并优化效率较低的代码部分，但拥有一个相对简单的架构有助于保持一切整洁，并使新团队成员易于加入项目。

你还应该避免代码库中的混乱。首先，尽可能修复所有编译警告：有些可能对你来说并不重要，但你不想冒错过显示真正问题的警告的风险。这是一件微不足道的小事，但每次你需要修改某些东西时都会增加难度。此外，只实现你需要的方 法，不要保留旧代码，以限制你必须维护的代码量。如果你以后需要重用你删除的代码，你可以随时从你的源代码管理系统中检索它。

限制外部库的数量

Android 和 Java 世界中有很多优秀的库可用。但是，虽然使用库可以节省你的时间，但它也有一定的成本：当你升级应用程序以支持最新的 Android 版本时，你还需要升级你使用的所有库。每个依赖项都是你项目的一部分，它可能会中断，而且你无法直接控制它。库也可能停止升级，最终需要重构到替代方案，或者需要你付出代价来维护旧库。

另一方面，如果你需要快速制作原型或添加一个构建起来需要很长时间的组件，使用库是值得的。但对于可能成败攸关的关键任务，最好根据你的需求自己实现。幸运的是，没有什么能阻止你从现有的库中学习来创建自己的东西。你可能更喜欢使用标准 Android SDK 版本中的方法，即使它们的实现不是最好的：它最有可能在各种设备上经过测试，并且长期维护。

你的产品并非你的调试版本

如果你的代码从开发机器加载到测试设备时能正常工作，那就太好了，但这并不是你工作的结束。你需要至少在几台更多设备和 Android 版本上测试你的发行版，以确保它在发布到商店后能够正常工作，因为并非所有使用你应用程序的用户都与你拥有相同的设备和操作系统版本。你还需要在新的 Android 操作系统版本发布后持续进行测试，以免它对喜欢将设备更新到最新版本的用户的应用造成损坏。

此外，如果你的应用程序不是通过 Google Play 商店部署的，你可能还需要为你的应用程序添加某种形式的调试功能，例如可以切换以向你报告问题的日志模式：当只有你的应用程序崩溃的信息时，帮助用户可能会非常困难。最后，你还需要为你的用户准备一些文档，除非你的应用程序非常简单。你网站上的一个简单的常见问题解答就足够了，但不要让你的用户完全摸不着头脑地尝试理解你的应用程序。这将减少支持请求的数量，并在问题开始出现时为你提供一些现成的答案。