回顾我这一年多的 Git 提交日志

最新推荐文章于 2024-03-23 09:44:51 发布

安卓进化论

最新推荐文章于 2024-03-23 09:44:51 发布

阅读量362

点赞数

本文链接：https://blog.csdn.net/D29h1jQy3akVx/article/details/84001546

版权

640

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

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

刚入职一个多月的提交

640

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

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

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

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

入职两个多月的提交

640

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

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

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

入职三个多月的提交

640

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

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

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

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

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

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

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

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

使用英文作为日志的提交

640

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

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

上线一个大功能前的提交

640

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

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

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

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

避免直接依赖

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

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

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

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