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

版权声明:转载前请留言获得作者许可,转载后标明作者 张拭心 与 原文链接。大家都是成年人,创作不易,感谢您的支持! https://blog.csdn.net/u011240877/article/details/84001196

一眨眼已到 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() 的实现不熟悉;对 LruCachemaxSizesizeOf() 理解不到位;对 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 奔溃、强杀应用,这种状态恢复到正常状态后,如何恢复现场呢?客户端样式状态最好以服务端为准,一些比较敏感、常变的可以使用轮询。

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

优化相关的提交

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述在这里插入图片描述

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

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

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

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

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

总结

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

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

改进意见:

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

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

没有更多推荐了,返回首页