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