澳洲体育类视频项目接触一个月的体验总结

时间过得好快，距离我加入澳洲团队已经一个月了，当初面试我的面试官也变成了我的直属上司。在这一个月中我也接触了很多新的东西。今天就对这一个月以来学习到的新东西做下简单的总结。

Firebase Remote Config

之前接触到的海外项目当中，除了用到用于上线 Android 应用的 Play Store 外，几乎没怎么用到过 Google 的其他的产品，而现在这个项目几乎是以 Remote Config 为核心来构建的，可以说如果 Firebase Remote Config 在一段时间内不可用的话，这个 App 几乎处于瘫痪的状态，不过 App 本地也有一些缓存策略来防止这种情况发生。
这个项目贯彻了一切皆配置的原则，为此还单独创建一个 Remote Config 项目，来把 Config 来给工程化，涉及到配置的改动都要 PR 和 Team Leader 来 Code Review，然后由 CircleCI 来自动化部署。
为什么说一切皆配置呢，因为 App 里用到的文字、图片、Api 请求的 url、首页展示的数据以及部分业务逻辑都是放到配置里的。我甚至怀疑他们的 Config 已经达到了 Firebase Remote Config 的存储上限，以至于把部分配置 Json 放到 amazon 的 S3 上。

Android Studio 设置 - 代码阅读更友好

进入 team 的第一天，除了一些账号的邀请外就是按照 Leader 的要求同步下 Android Sutdio 的设置，这一步也是为了防止我在修改代码后格式化的时候破坏当前代码的格式。
设置也很简单，在 Preferences/Settings -> Editor -> Code Style 下 Hard wrap at:改为 100 -> 200，效果就是是让代码辅助竖线右移，代码不要过早的换行，让代码更容易阅读。

如何排列一个类的成员从而被更容易阅读

这个没有被 Leader 明面上要求，不过写到了项目的Readme里，可见也非常的重要

Class layout
1. companion objects
2. public vars & vals
3. protected/private vars & vals
4. init method
5. public functions
6. protected/private functions

在践行过一段时间后，这种方式写出来的代码阅读起来也确实规正很多。

Ktlint 代码格式审查

也是在第一天就交代我要用到的，在提交代码前用./gradlew ktlint命令行检查一下，出现错误提示就改正。
Ktlint 的引入也非常简单，参考这里
我们这里是单独一个ktlint.gradle文件

configurations {
    ktlint
}

task ktlint(type: JavaExec, group: "verification") {
    description = "Check Kotlin code style."
    main = "com.github.shyiko.ktlint.Main"
    classpath = configurations.ktlint
    args "src/**/*.kt"
    // to generate report in checkstyle format prepend following args:
    // "--reporter=plain", "--reporter=checkstyle,output=${buildDir}/ktlint.xml"
    // see https://github.com/shyiko/ktlint#usage for more
}

task ktlintFormat(type: JavaExec, group: "formatting") {
    description = "Fix Kotlin code style deviations."
    main = "com.github.shyiko.ktlint.Main"
    classpath = configurations.ktlint
    args "-F", "src/**/*.kt"
}

dependencies {
    ktlint "com.github.shyiko:ktlint:0.23.1"
}

然后在项目级的build.gradle里配置下即可

1
2
3

subprojects {
    apply from: "../ktlint.gradle"
}

如何让 Git Commit History 保持整洁规范

除了 git 合并分支用rebase外，另外一种办法就是一个任务只允许一个 Commit，当产生多个 Commit 时就必须Combine to one操作一下，这样每个 PR 只有一个 Commit 里涉及到所有的代码改动，这样也便于后面需求变动是时更容易定位。

我对现在这种工作方式的看法

一上来就这么要求这么多，一开始确实有点不适应，不过时间长了好处也显而易见，毕竟是一个团队，在开发习惯上尽量往有共识的方向上靠，这样才能更好的帮助团队成长。