回顾我这一年多的 Git commit 日志

待我称王封你为后i 2022-04-17 04:11 190阅读 0赞

一眨眼已到 2018 年底，我入职喜马也一年多了，这一年里成长了不少，但对外输出少了很多，主要原因还是太懒。

今天趁懒癌没发作，跟着 git 提交日志，回顾一下这一年多写的代码。

# 刚入职一个多月的提交 #

![2017.10][]

可以看到，我的提交日志还是比较清晰的，当次提交做了什么，基本可以一目了然。

刚开始那一个月，主要是熟悉项目，然后做一些比较简单、关联性比较低的需求，比如直播首页、个人资料卡的修改。

新人对项目了解不够，最好不要一上来就分配业务状态比较复杂、涉及面比较广的需求，那样风险太大。

这个阶段我做的还算可以，变量、常量命名合理易懂，异常情况考虑的也还算周到，上线后基本没有什么 bug（其实是做的功能比较简单哈哈）。

## 入职两个多月的提交 ##

![2017.11][]

十一月主要做的是创建直播，这个需求比较典型，是一个页面有多种状态，编辑、预览、修改等等。

开发这种页面样式、接口比较相似的需求，最好抽象出共同的基类或者接口，然后根据不同逻辑选择不同的实现，避免在其中通过 `if-else` 添加各种判断逻。这种模式就是常说的“策略模式”。

比如我这样：

private ILiveCreateOrEdit getImplByType(int type) {
        switch (type) {
            case TYPE_LIVE_PREVIEW:
                return new LivePreviewInfoImpl();
            case TYPE_PREVIEW_EDIT:
                return new LivePreviewEditImpl();
            default:
            case TYPE_COMPOSE:
                return new LiveCreateImpl();
        }
    }

`ILiveCreateOrEdit` 里定义了创建直播、直播预告、编辑直播都要有的功能，比如初始化 ui ，请求接口，点击固定按钮的逻辑。

三个实现里完成对应状态的布局显示和接口请求，避免了使用 if-else 的杂乱。

不仅仅是页面相似的，逻辑相似的，也可以使用这种模式。比如一些图标、徽章、挂件的下载、查询，都是一样的逻辑，我都把他们放到了一个管理器里，定义接口然后再具体实现。

我们新开发一个需求时，不急着实现，可以先花点时间想想现有的哪些需求可能和这个类似，能否把他们的逻辑抽象出共同之处，这样后面有类似的需求可以基于这个共同的直接进行拓展开发，看似现在是多做了工作，其实是为以后节省时间。

> **继承优于拓展**

> 重复使用的布局、类，最好抽象出共同的基类或者接口，然后通过继承实现，避免在其中通过 if-else 添加各种判断逻辑。

> 以前总喜欢把一个类用到很多业务，结果导致在里面充斥了大量的判断代码，时间久了自己维护都费劲，实在是不好的风格。

## 入职三个多月的提交 ##

![2017.12][]

从日志可以看到，这个月我主要在解决一些 bug。

其中一部分问题属于 UI 问题。我开发时遇到不太舒服的样式、交互会自行修改，然后拿着修改后的找产品、设计师沟通，有的时候他们会被我的机智所打动，同意修改。但更多时候，我的意见都被驳回，看来我的审美还是不够好 0.0。

还有一部分问题是\*\*“过度优化”导致\*\*的。有时候写业务，不由自主的想优化一下，比如复用、回收、预加载。本意是好的，但奈何我心太粗，只想着优化的好处，没有针对优化可能导致的问题做出处理。比如复用时的状态异常处理，对象池的额外开销，预加载选择的时机等等。

> 任何优化都是双刃剑，不仅要考虑益处，也要考虑代价。

再有就是**对自己写的代码不熟悉**导致的。比如对 `View.post()` 的实现不熟悉；对 `LruCache` 的 `maxSize` 和 `sizeOf()` 理解不到位；对 `CopyOnWriteArrayList` 的迭代器不熟悉；对项目组件生命周期不熟悉等等。

**对项目、对运行在诸多用户上的代码要有敬畏心，对自己所写的要尽可能多的理解，确保没有问题。**

最后就是那时候**提交代码没有养成 review 的习惯**，偶尔会提交了错误的代码，比如 refactor 影响到不相干的代码。后面纠正了这个问题，commit 前基本都会检查。

**做的不好的是，在提交 log 里没有写清楚 bug 原因，对于一些可能再次犯的问题，应该在 log 上写清楚。**

## 使用英文作为日志的提交 ##

![english log][]

这个阶段我不知道吃了什么药，开始使用英文写提交日志，可能觉得很酷吧。

回过头再看，发现这种提交，根本不直观，因为一些细节不好用英文表达，提交日志就写的比较简单、模糊，在后面排查问题时，无疑增加了难度，不太建议这样。

## 上线一个大功能前的提交 ##

![2018-friends-mode][]

五六月份开发了一个相对复杂的功能，这个功能涉及到的状态、异常情况比较多，出的 bug 就比较多，于是有了上面这样整齐的解决 bug 日志。

这个经历能学到哪些知识呢？

拿到需求，先不考虑如何实现，而要考虑这么做是为了什么，知道目标后，哪怕当前需求因为技术无法实现或者实现成本太大，也可以尝试提出替代方案，而不至于直接推掉。

拿到业务，先分层，界面 -> 数据 -> 消息，虽然代码不是 MVP 模式，但思考可以像 MVP 一样先定义各层接口，然后确定依赖，不同类之间尽量不要直接依赖类，而要依赖一个接口。

> **避免直接依赖**

> 类 B 中调用类 A 很多方法的话，就让类 A 实现接口 X，然后 B 持有 X 的引用，那样将来类 A 修改继承自谁，也不会影响这些旧代码。

> 也不要直接调用其他类的成员，通过 getter 方法调用，那样在值异常时做一些处理可以直接在方法内部完成，而不需要修改所有调用的地方。

还得**重视异常情况的处理**。比如弱网、飞行模式、app 奔溃、强杀应用，这种状态恢复到正常状态后，如何恢复现场呢？客户端样式状态最好以服务端为准，一些比较敏感、常变的可以使用轮询。

以服务端数据为准，但**客户端要做好兜底**，直接影响状态的数据要做兜底，数据异常时提供默认状态好过显示异常。

## 优化相关的提交 ##

![在这里插入图片描述][2018111300023410.png]  
![在这里插入图片描述][20181113000240892.png]  
![在这里插入图片描述][20181113000250604.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyNDA4Nzc_size_16_color_FFFFFF_t_70]![在这里插入图片描述][20181113000306108.png]

可以看到，我的优化日志也不够详细，没写清楚都做了什么优化。以后得把优化的内容也写明白。

静态代码检测帮助我发现了很多细节问题，比如：

*  `StringBuilder` 要拼接的字符串大于 16 时，构造需要声明初始容量，不然会频繁扩容
 *  在使用 `StringBuilder.append()` 方法连接**字符**时，避免使用 `string` 类型，用 `char` 类型连接字符
 *  不要 new 包装类，使用 `valueOf()` 方法代替
 *  `Integer.parseInt()` 和 `Integer.valueOf()` 的正确选择
 *  `DateFormat` 的多线程不安全问题
 *  …

还有一些业务逻辑的优化，比如数据对比、局部刷新、动画效率、内存泄漏等等，都是比较常见的。业务需求比较多，在性能方面做的还不够，这一点比较惭愧。

和领导沟通，说到，除了敬畏心、责任心，开发还需要具备追求完美的心态，对自己写的项目要多玩、多用，主动发现不足之前并优化。后面我得更加关心性能和体验。

# 总结 #

在没有养成写周报、正确对待提交日志的习惯之前，我在回忆工作内容时，常常会很迷茫，记不起自己究竟做了什么，学到了什么，产生了什么价值。

过去的这一年多，我的提交日志还算有些价值，跟着日志简单回顾了一下这一年多做的事，发现可以改进的地方很多，后面还得继续努力才行啊！

改进意见：

1.  log 信息前面使用 tag 标明分类，\[feature\] \[fix\] \[perf\]
2.  提交粒度要够细，以备不时之需，完成独立的功能就提交
3.  日志信息要写清楚，做了什么功能，解决了什么问题（原因是什么），优化了什么（有什么改进）
4.  需要经常回顾工作内容，提出改进意见

--------------------

> 欢迎关注我的公众号，阅读更多个人管理、职业发展、知识体系、技术原理、面试经验文章

![20160923012706321][]

[2017.10]: /images/20220417/c7f9d39bd8114653a9508cedef256300.png
[2017.11]: /images/20220417/273da4a46a7b4f508b96ce46c8e11e91.png
[2017.12]: /images/20220417/cff67e5b811a48e1852c72a3a6d1192b.png
[english log]: /images/20220417/25b2c8a348af4d2ea80aa67d4b8dc970.png
[2018-friends-mode]: /images/20220417/26ea44cac84f46e19369bb64890af856.png
[2018111300023410.png]: /images/20220417/753c24e6cce74a33abaab733a3defca1.png
[20181113000240892.png]: /images/20220417/92d11f287ffd4085b1fe9cb2a6dc15ee.png
[20181113000250604.png]: /images/20220417/607b3bb5b10c42e2af39fbed3ce3d654.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyNDA4Nzc_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20181113000257124.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEyNDA4Nzc=,size_16,color_FFFFFF,t_70
[20181113000306108.png]: /images/20220417/2c73ea5604f641b3b163ce05493d610a.png
[20160923012706321]: /images/20220417/3c6ad263250b46119ddd896d04502a63.png