当前位置:   article > 正文

2018 终了,是时候秀出我的 Git 进化日志了!

git进化

640?wx_fmt=gif

640?wx_fmt=jpeg

作者 | 拭心
责编 | 郭芮

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


640?wx_fmt=png

刚入职一个多月的提交


640?wx_fmt=png

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

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

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

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


640?wx_fmt=png

入职两个多月的提交


640?wx_fmt=png

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

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

入职三个多月的提交


640?wx_fmt=png

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

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

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

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

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

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

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

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


640?wx_fmt=png

使用英文作为日志的提交


640?wx_fmt=png

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

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


640?wx_fmt=png

上线一个大功能前的提交


640?wx_fmt=png

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

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

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

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

避免直接依赖;

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

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

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

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


640?wx_fmt=png

优化相关的提交


640?wx_fmt=png640?wx_fmt=png640?wx_fmt=png640?wx_fmt=png640?wx_fmt=png

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

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

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

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

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

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

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

  • …...

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

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


640?wx_fmt=png

总结


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

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

改进意见:

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

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

  • 日志信息要写清楚,做了什么功能,解决了什么问题(原因是什么),优化了什么(有什么改进);

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

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

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

 热 文 推 荐 

燃爆了!胡歌秒变最帅产品经理发布荣耀V20!

BAT 缩招,AI 跻身 2019 年最赚钱职业榜首!(附薪酬表)

支付宝辟谣交易 5 万受监控;App Store 宕机;谷歌抛弃 AI | 极客头条

雷军:执掌金山纯属意外

关于5G接入网,看这一篇就够啦!

别说创业维艰,16岁开发者从辍学歧视死亡威胁, 到开发出爆款应用, 她的人生远非成人想象

AI in 美团:吃喝玩乐背后的黑科技

老程序员肺腑忠告:千万别一辈子靠技术生存!

 
 

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

640? 喜欢就点击“好看”吧!
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小丑西瓜9/article/detail/68299
推荐阅读
相关标签
  

闽ICP备14008679号