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 看，不要怀着心虚去写代码