阅读 155

吾日内省

11-13

  • 1.工作期间打开社交软件次数过多,需要优化到3次以下,前期寻求软件层面的控制,后期自制。
  • 2.写代码前需要做的几件事情:
    • 1.了解代码的上下文结构
    • 2.了解所调用 api 可能会返回的数据类型
    • 3.了解业务逻辑
    • 4.处理业务数据需要注意下面这些问题:
      • 1.了解数据表示的意义
      • 2.了解数据的消费方,以及修改后对消费方的影响。
      • 3.了解数据被处理前后的状态。

11-14

  • 1.写代码时,使用好 library 是一个非常能提高效率的事情,比如 guava 这个 google 的 java 工具库的使用:集合功能、参数检查、区间范围、字符串操作、缓存、各种工具方法、多线程等等。
  • 2.写代码就如同搭积木,对每个方法的入参需要了解其传入的可能性,了解了之后就需要使用一些工具对入参进行检查,如果不对就提早抛出问题,而不是等到后面某个地方抛出 exception。例如Preconditions。
  • 3.在想用一个工具代码的时候,遵循下面的搜索路径:search jdk ——> search guava—— >search others library ——> write you own

11-15

11-16

  • 1.protobuf 的 message get 的时候返回的不可能是 null,集合默认返回空,对象会返回默认对象

11-19

  • 1.工作注意力不够集中,效率不够高,需要找方法优化:
  • 2.23点之后工作学习效率低下,尽量做一些放松的事情比如看闲书看电影:达到要求,娱乐时间目前集中在23点以后
  • 3.编程时数据流需要清晰,确认数据处于某种状态之后(比如不为null),就不需要对其进行保护。只有确认为不确定的数据才需要保护。
  • 4.在写某个代码流程的时候(比如 canvas 绘制),整个流程的开始和结束要由一个 owner(可以是某个方法,或者类中配对的方法) 来操作。这个规则类似业务边界限制,能够有效解耦代码流程。防止代码流程的状态混乱。

11-26

  • 1.接手他人代码或进入一个成熟的项目写代码就如带着镣铐跳舞
    • 1.要遵循原有代码的设计,除非对代码非常熟悉,而且非常需要修改,不然不要另起炉灶。
    • 2.对于需要修改的部分,需要从数据结构入手,了解了数据结构代表的意义才能开始进行老代码的修改。
  • 2.大项目的开发,性能是很重要的点。可能开发之前运行的好好地,但是因为加的代码让性能差了一点,然后因为雪崩效应,就造成了整个 app 的 anr 或者 oom。注意以下事项
    • 1.开发的时候手机不能太好,太好的手机会掩盖很多问题,而这些问题在低端机型测试的时候就会暴露出来,之后就会造成在性能差的代码上面加补丁这种现象。结构差、性能差的代码需要在开始编码的时候就注意
    • 2.音视频开发中,除了网络请求和文件读取,还会使用到很多耗时长的 api,这些 api 在开发的时候一不注意就会在主线程调用。这也是需要极力避免的事情。

12-19 项目复盘

  • 1.改进
    • 1.在开始需求之前能了解到部分需求边界,这个比之前有进步。
    • 2.git 提交格式有改进
    • 3.不随意造轮子,能使用现有工具
  • 2.问题
    • 1.需求边界了解的不是很彻底,正式开始写代码之后有些 case 才被发现,这个需要持续改进
    • 2.如果不清楚所有已经被他人依赖了的代码的调用处的逻辑,那么就别去修改他,即使这个代码是有问题的。
    • 3.千万别在不了解业务的状态下优化代码,无论是代码结构还是代码性能。
    • 4.对于打日志,需要根据具体代码情境打相应级别的日志,不可一刀切只打 info 或者 debug。
    • 5.在开始写需求之前一定要花一定的时间确定代码的整体设计。这个设计需要能融入现有的代码体系,不可自起炉灶。
    • 6.如果上线前使用的测试环境的数据有问题,需要以线上环境的数据为标准,然后辅助以临时代码进行修正。千万别基于测试环境的数据进行代码的编写。
    • 7.数据与逻辑需要进行分离,切不可将逻辑与数据进行耦合。只要某个数据产生了,那么让逻辑配合数据,而不是数据配合逻辑。
    • 8.开发过程中,除非实在无法解决,否则不可临时写一个解决方案,然后期待后面解决。因为一旦代码写下了,那么后续就会有代码依赖,后面解决的成本永远比现在解决的成本高。
    • 9.时刻注意调用他人的 api时,其 api 需要处于的线程

2019年开始

01-07 项目复盘

  • 1.改进:
    • 1.需求开始前,能完整的整理出需求的流程
    • 2.需求开始前,能写技术文档
    • 3.需求开始前,能基本了解涉及的代码的逻辑
    • 4.不随意造轮子,用上了 guava
    • 5.没有再随意改动和优化老的逻辑
    • 6.review 后重写代码的量有减少
  • 2.问题:
    • 1.除非万不得已,千万不要定义一块在程序的生命周期内永远也释放不掉的内存,比如不被置空静态常量。要尽量让内存随着处理的逻辑走,或者使用弱引用这些可被回收的东西。
    • 2.使用观察者模式的时候注意要在适当的时候进行注册和反注册,以免在不需要观察的时候接收到事件。比如 eventbus在 fragment 销毁之后还在接收事件。需要注意的是handler 的 post 会让一个事件延后进行,这样也会造成未知的问题
    • 3.代码的可阅读性非常重要,在写代码的时候要时常问自己,如果是一个新手过来看代码他能看得懂吗?
    • 4.代码逻辑一定要跟着数据走,数据简练而且正确,那么代码逻辑也就会简练正确。
    • 5.要时刻注意生命周期这东西,不管是数据的生命周期、还是需求的生命周期、还是操作流程的生命周期、还是 Activity 的生命周期。

01-15 项目复盘

  • 1.改进:
    • 1.无。。。
  • 2.问题:
    • 1.需要将一个东西的初始化的全部代码放在一个代码区域。而不是让初始化逻辑散落在各个地方,然后靠某个id 或者其他东西将不同的地方的数据连接起来。这样会造成以下问题:
      • 1.给后面接手代码的人留坑,一不小心就会漏加了某个初始化的逻辑
      • 2.这样的代码是低内聚的
    • 2.还是要注意对一个数据块全部生命周期的控制,申请了一块内存就要去找地方释放它。对于 java 类语言来说就是不引用它了,对于 c/c++ 类语言来说就是手动 delete
    • 3.如无必要勿增实体,这句话出自“奥卡姆剃刀”。在写代码上体现的就是:在保证业务逻辑的前提下,尽量定义或使用最简单的数据结构,数据结构越简单写出来的逻辑就越简单,千万不要使用无效的中间数据结构
    • 4.不要保证临时代码的想法去写代码。 在开始写代码的时候就想好整个结构,比先写代码然后后面去调整结构效率会更高。

03-05

  • 1.不要把某些事情不当回事,这些事情最终可能演变成大事情。预防比治理方便百倍。
  • 2.对外提供的 api,不要包含当前层次不需要做的事情,有些事情应该交给被调用者做。也就是说 api 的内部实现需要对调用者是透明的,调用者不用去搞清楚 api 的内部实现也可以顺利调用。
  • 3.presenter 需要数据和 ui 一起拆,presenter 之间不需要太多的数据交互
  • 4.不管是写代码还是改 bug 有时候需要找到问题的本质,而不要只要改表面的问题。跳出当前的思维局限,就能找到更好的办法。
  • 5.在改代码的时候一定要跳出原来的思维,以新的思路想想
  • 6.接手别人未测试的代码的时候一定要完整的了解他们写的东西,不然坑很大
  • 7.尽量将回答他人的话用实际证明,看代码的时候路径这些东西可以 debug 看,不要怀着心虚去写代码
关注下面的标签,发现更多相似文章
评论