吾日内省

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