2018 终了，是时候秀出我的 Git 进化日志了！

作者 | 拭心
责编 | 郭芮

一眨眼已到 2018 年底，我入职喜马也一年多了，这一年里成长了不少，但对外输出少了很多，主要原因还是太懒。今天趁懒癌没发作，跟着 Git 提交日志，回顾一下这一年多写的代码。

刚入职一个多月的提交

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

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

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

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

入职两个多月的提交

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

开发这种页面样式、接口比较相似的需求，最好抽象出共同的基类或者接口，然后根据不同逻辑选择不同的实现，避免在其中通过 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 添加各种判断逻辑；

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

入职三个多月的提交

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

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

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

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

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

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

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

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

使用英文作为日志的提交

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

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

上线一个大功能前的提交

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

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

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

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

避免直接依赖；

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

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

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

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

优化相关的提交

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

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

• StringBuilder 要拼接的字符串大于 16 时，构造需要声明初始容量，不然会频繁扩容；

• 在使用 StringBuilder.append() 方法连接字符时，避免使用 string 类型，用 char 类型连接字符；

• 不要 new 包装类，使用 valueOf() 方法代替；

• Integer.parseInt() 和 Integer.valueOf() 的正确选择；

• DateFormat 的多线程不安全问题；

• …...

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

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

总结

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

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

改进意见：

• log 信息前面使用 tag 标明分类，[feature] [fix] [perf]；

• 提交粒度要够细，以备不时之需，完成独立的功能就提交；

• 日志信息要写清楚，做了什么功能，解决了什么问题（原因是什么），优化了什么（有什么改进）；

• 需要经常回顾工作内容，提出改进意见。

作者：张拭心，长期在 CSDN 上写作，CSDN 博客专家，公众号“zsx跃迁路”维护者。热爱读书写作，目标是写出有趣的技术书，目前研究方向为前端和移动端。本文来源于个人博客：https://blog.csdn.net/u011240877/article/details/84001196。

声明：本文为作者投稿，版权归其个人所有。

 热 文 推 荐 

print_r('点个好看吧！');
var_dump('点个好看吧！');
NSLog(@"点个好看吧！");
System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！\n");
cout << "点个好看吧！" << endl;
Console.WriteLine("点个好看吧！");
fmt.Println("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"

喜欢就点击“好看”吧！