一句话感悟
1. 当设计一个类时,如果需要将数据处理后给到外部对象,那么如果说不是特别需要(隐私数据),那么应该要携带上原始数据和数据来源,这样外部可以知道更多内容,做出不同的处理。
2. 当一个问题不知道如何处理时,将你的疑惑、阻碍、麻烦、难点一一列举出来进行分析,找到一个能消灭最多点的方案
3. 慎重的对待自己的修改,尤其是基础的组件,哪怕是一些小的影响,都应该回归一些
4. 自己完成一件事情,还需要能和别人讲述明白,才能长久
5. 操作跳转流程和数据来源都需要了解
6.慎重、严谨的对待自己的组件和依赖库的更新,团队开发中一个依赖库的修改,可能伴随着多个其他库的修改,意味着其他同事不得不将这些库都同步到和你一样的版本,否则当你的代码合入开发分支,其他同事拉取新代码之后就会报错。
7.别人给的是建议,具体方案还是要看开发人员自己,不要忘记去思考,这个改动是否合理。
8.严谨自测,全流程自测,确保给到测试的包没有问题
9.需要按subspecs引入组件时,需要按需添加,如果不设置的话,默认使用配置的分库作为引入内容,否则相当于引入的空内容
10.当有多个不同的配置时,不同配置下的代码逻辑一定要仔细核对,多阅读文档多看消息记录多问多去确定,绝不要等到代码提交之后发现出错了...
11.复杂的业务不是说页面有多复杂,而是你要掌握每一个数据的 产生、修改、更新、使用 的整个流程
12.处理任务依赖,给所有任务赋予唯一标识,设置依赖时需要根据标识来设置,每个任务都必须存在并调用任务完成时的回调,等待的任务需要设置超时逻辑,等待的任务在存在一个数组保存当前等待完成的任务(可能添加进来时有些任务就已经完成了),每当一个人任务完成,更新在等待任务的依赖项目,如果没有在依赖的任务,则进入触发等待池,触发任务执行。
13.出现问题时不要放大问题,也不会忽视问题,严谨正确地判断问题和原因和影响范围。例如:pod引入自己创建的库报错头文件找不到,先确定是不是全部找不到还是部分找不到?进而确认是库配置异常,还是项目配置异常?或许报错的只是某几个文件(它们属于其他Target在pod执行时没有添加依赖)。
14.跟踪一件事情最好是一个人来处理,切换人员将导致传达错误的风险。基础的事件一定要先行,并行的话因为存在依赖,将可能导致流程或实际效果异常
15.突然出现奇怪的问题时,考虑一下是否是新接入的东西带来的影响,比如新的库有增加 +load 方法 做了方法替换
16.提供block给到业务方进行终止回调或者是进行决策时,应该注意到业务端对block多次调用的情况,这样是很有可能影响到基础库内部处理的
17.涉及到其他人的代码修改,一定要先确认清楚。写代码的人也要注意规范,例如 waring error todo 这些东西,谨慎使用,代码摆放的时候也要注意,防止其他人理解错误而误删