Have you ever experienced something like this:
您是否曾经经历过像这样的事情:
- Have a great idea for a weekend project 有一个周末项目的好主意
- Create a new repository 创建一个新的仓库
- Setup a proper CI to build your project 设置适当的CI以构建您的项目
- Setup a code formatter to enforce code-style 设置代码格式化程序以强制执行代码样式
Start reading articles about
[tool name here]
...开始阅读有关
[tool name here]
...- Weekend is over 😅 周末结束😅
- Repeat 重复
That’s how a lot of side-projects of mine died in the past.
这就是我过去的许多附带项目死亡的原因。
I love developer-tools such as CIs and static-analysis tools. They’re crucial to deliver good quality code, and I can’t imagine working without them. They’re generally the first thing I set up before starting a new project.
我喜欢CI和静态分析工具之类的开发人员工具。 它们对于提供高质量的代码至关重要,没有它们我无法想象。 在开始新项目之前,它们通常是我设置的第一件事。
Unfortunately, setting up such tools can be time-consuming, especially if you’re not familiar with a specific tool and how to configure it.
不幸的是,设置此类工具可能很耗时,特别是如果您不熟悉特定工具及其配置方法时。
That’s why throughout the years I crafted my own project templates. They help me kick off a project if I have a new idea in mind, without having to spend time configuring everything from scratch.
这就是为什么多年来我精心制作自己的项目模板的原因 。 如果我有新想法,他们可以帮助我启动一个项目,而不必花费时间从头开始配置所有内容。
Recently I’ve spent some time polishing them and open-sourcing some of them. They’re now available for everyone to use with Github templates with just one click.
最近,我花了一些时间对它们进行修饰,并将其中的一些开源。 现在,每个人都可以通过一次单击将它们与Github模板一起使用。
Here you can find my Android App/Library template:
在这里您可以找到我的Android应用程序/库模板:
In this blog-post, I will walk you through the steps I do before starting an Android project and that you can find already applied in the linked template.
在这篇博文中,我将引导您完成启动 Android项目之前的步骤 ,并发现已在链接模板中应用了该步骤。
1.格式:ktlint (1. Format: ktlint)
The clear choice I made in this template is to have it as a 100% Kotlin template. I believe that in 2020 is safe to assume that you can start your new Android project with Kotlin only.
我在此模板中做出的明确选择是将其作为100%Kotlin模板。 我相信在2020年可以安全地假设您只能使用Kotlin启动新的Android项目。
I generally don’t start writing code without a good formatter to support me. Having several comments on your pull-requests about where to place parenthesis or extra white-spaces can be pretty annoying. A formatter can help you ship beautified code and avoid useless discussions.
我通常不会在没有好的格式化程序来支持我的情况下开始编写代码。 在关于放置括号或多余空格的位置的拉取请求中有几条评论可能会很烦人。 格式化程序可以帮助您发布美化的代码并避免无用的讨论。
For Kotlin my preferred formatter is ktlint:
对于Kotlin,我首选的格式化程序是ktlint :
I use the ktlint-gradle plugin to integrate it into my build.
我使用ktlint-gradle插件将其集成到我的构建中。
With that, running:
这样,运行:
./gradlew ktlintFormat
will reformat the entire codebase.
将重新格式化整个代码库。
Ktlint-gradle comes with other tasks that can help speed-up developer’s productivity with IntelliJ integration and pre-commit hooks:
Ktlint-gradle附带了其他任务,这些任务可以通过IntelliJ集成和预先提交的挂钩来帮助提高开发人员的生产力:
# Will update IntelliJ/AndroidStudio reformat rules to
# match the ktlint style.
./gradlew ktlintApplyToIdea
# Will set up a pre-commit hook that will run
# reformat the code before a git commit.
./gradlew addKtlintFormatGitPreCommitHook
If you happen to use Gradle Kotlin DSL, ktlint will conveniently reformat also your
.gradle.kts
file.如果您碰巧使用Gradle Kotlin DSL ,则ktlint也会方便地重新格式化
.gradle.kts
文件。
2.分析:检测和皮棉 (2. Analyze: detekt & lint)
Other than beautified, we want our code to be bug-free.
除了美化之外,我们还希望我们的代码没有错误。
That’s where static analyzers can help spot bugs before the code goes to production. I always configure those two static analyzers on my projects:
在那里, 静态分析器可以在代码投入生产之前帮助发现错误。 我总是在项目中配置这两个静态分析器:
(Android) Lint: A language-agnostic analyzer that will help you spot Android-specific bugs (e.g., unused resources or hard-coded text).
(Android)Lint :一种与语言无关的分析器,可帮助您发现Android特定的错误(例如,未使用的资源或硬编码的文本)。
Detekt: A Kotlin specific analyzer that can help you find potential errors or anti-patterns in your Kotlin code.
Detekt :Kotlin专用的分析器,可以帮助您在Kotlin代码中查找潜在的错误或反模式。
Lint is available out of the box directly inside Android Studio.
Lint可以直接在Android Studio内部使用。
Detekt is instead a command-line tool and can be included in the build with a Gradle plugin.
Detekt是一个命令行工具,可以通过Gradle插件包含在构建中。
Once set up, invoking:
设置完成后 ,调用:
./gradlew detekt
is enough to run the static analyzer on the whole codebase.
足以在整个代码库上运行静态分析器。
I personally find useful also the detekt IntelliJ plugin. It will run the detekt inspection directly inside Android Studio without having to run an extra task.
我个人觉得detekt IntelliJ插件也很有用。 它将直接在Android Studio内部运行检测检测,而无需运行额外的任务。
3.管理依赖项:buildSrc (3. Manage dependencies: buildSrc)
I prefer to use the Gradle Kotlin DSL to write my build files. It comes with nice features such as auto-completion and semantic editing.
我更喜欢使用Gradle Kotlin DSL来编写我的构建文件。 它具有不错的功能,例如自动完成和语义编辑。
To manage dependencies I use the buildSrc
included build. This allows organizing libraries and versions with a Dependencies.kt file such as:
为了管理依赖项,我使用了buildSrc
附带的构建。 这允许使用Dependencies.kt文件来组织库和版本,例如:
object Versions {
const val APPCOMPAT = "1.1.0"
const val CORE_KTX = "1.2.0"
const val JUNIT = "4.13"
}
object SupportLibs {
const val ANDROIDX_APPCOMPAT = "androidx.appcompat:appcompat:${Versions.APPCOMPAT}"
const val ANDROIDX_CORE_KTX = "androidx.core:core-ktx:${Versions.CORE_KTX}"
}
object TestingLib {
const val JUNIT = "junit:junit:${Versions.JUNIT}"
}
Those versions and coordinates are available to every build script in the project. Declaring a dependency is as easy as:
这些版本和坐标可用于项目中的每个构建脚本。 声明依赖关系很容易:
Moreover, I’m using the Gradle Plugin DSL to apply Gradle plugins instead of the old apply:
statement.
此外,我正在使用Gradle插件DSL来应用Gradle插件,而不是旧的apply:
语句。
Setting up a new module is a matter of just:
设置新模块仅需:
plugins {
id("com.android.library")
kotlin("android")
}
The buildscript {}
block is not needed anymore. Plugin versions are defined in the top-level build.gradle.kts
file, while repositories are declared in the settings.gradle.kts
file.
buildscript {}
块不再需要。 插件版本在顶级build.gradle.kts
文件中定义,而存储库在settings.gradle.kts
文件中声明。
4.构建:Github动作 (4. Build: Github Actions)
To build and test my project, I always set up a continuous integration environment. This allows running tests in isolation and ensuring consistent code formatting/static analysis on every commit.
为了构建和测试我的项目,我总是建立一个持续的集成环境。 这允许隔离地运行测试,并确保每次提交时一致的代码格式/静态分析。
I’ve tried several CI services in the last years, but recently I’ve migrated a lot of my projects to Github Actions.
在过去的几年中,我尝试了几种CI服务,但是最近我将许多项目迁移到了Github Actions 。
In the template you can find two Github Actions workflows:
在模板中,您可以找到两个Github Actions工作流程:
pre-merge To build, test, run detekt & ktlint on all the modules of the project.
合并前要在项目的所有模块上构建,测试,运行detekt&ktlint。
gradle-wrapper-validation To validate the hash of the Gradle wrapper.
gradle-wrapper-validation验证Gradle包装器的哈希值。
Those workflows will run automatically for every new Pull Request and for every push.
这些工作流程将针对每个新的请求请求和每次推送自动运行。
Github Actions integrates well with Github templates: when you create a new repo from my template, you will have a CI setup already running, and you don’t need to set up extra services or create other accounts.
Github Actions与Github模板很好地集成:当您从我的模板创建一个新的仓库时,您将已经运行了CI设置,并且不需要设置额外的服务或创建其他帐户。
5.结论:维护模板 (5. Conclusion: Maintain a template)
Whenever I start a new project, I make sure to spend some time to update my templates to the latest market standards and tooling versions. I personally found project templates useful on several occasions:
每当我开始一个新项目时,我都要确保花一些时间将模板更新为最新的市场标准和工具版本。 我个人发现项目模板在几种情况下很有用:
When kicking off a new project, they get you started in some seconds and let you prototype fast your idea.
当启动一个新项目时,他们会在几秒钟内让您入门,并让您快速制作出原型。
When submitting bug-reports to open-source projects, they let you create an empty project to easily showcase how to reproduce a failure scenario.
向开放源代码项目提交错误报告时,它们使您可以创建一个空项目以轻松展示如何重现故障场景 。
When working on other projects, I often come back to my template to check how I configured a specific tool. They serve as documentation for my preferred setup.
在处理其他项目时,我经常回到模板中检查如何配置特定工具。 它们充当我首选设置的文档 。
I hope you found my template useful, and you get inspired to create your own. 💪
希望您发现我的模板有用,并能启发您创建自己的模板。 💪
If you want to talk more about this, you can find me as @cortinico on Twitter
如果您想更多地谈论这个,可以在Twitter上以@cortinico找到我
Originally published at https://ncorti.com on June 15, 2020.
最初于 2020年6月15日 在 https://ncorti.com 上 发布 。
翻译自: https://proandroiddev.com/my-android-project-template-1c0a7069ae31