在好未来实习了4个月左右，最近打算离职了，所以准备写一篇博客进行一下沉淀
持续更新中
1. 编程方面(python尽量使用类)
1.1 导包时
1.在做一个项目工程时，要把各个文件所在的目录分清楚，这样在导入不同文件夹下的文件时，会清晰很多。（使用python的sys.path）
2.按类别，按顺序导包：
导包时，一般分为三个大模块：
（1）python内置包，例如sys，os等，如果涉及系统路径，则需要在该模块下直接使用sys.path.append()，然后再进入下一个模块
（2）外部python依赖包，例如tensorflow、pyspark等
（3）外部自定义包，这里指的通常是自己写的py文件，或者其他人写的py文件，需要注意的是要直接import，不能使用类似from…import…(仅针对这一条)
import sys
import os
import json
sys.path.append(../)
import tensorflow as tf
import pyspark
# mypython是自定义
import mypython
1.2 有列表或者数组时，一定注意数组索引越界的情况，能用切片尽量使用切片
举个例子
a = [] 使用a[-1]会报错而使用a[:-1]不会报错
1.3 return格式一定要统一
举个例子，要不就return 后面什么都不写，要不就写return None
1.4 每个函数如果没有特定要求，建议有返回值
1.5 注意代码复用，提高代码开发效率
1.6 字典不能连续get，要在get之间进行判空
具体的，在具体开发过程中，尤其是线上代码开发过程中，对于字典，尽量使用get方法，禁止使用dict_[‘xxx’][‘xssa’]等去获取value，每一次get中间要进行try…except机制
1.7 养成写文档的习惯
leader给我的经验：
(1) 一个成熟的程序员在开发过程中，有1/3的时间在写代码，有1/3的时间在写文档，有1/3的时间在测试。
(2) 对于一个函数而言，除了考虑时间复杂度和空间复杂度以外，他在线上和测试的时候方不方便测试，这是一个很重要的对函数写的好不好的评价指标
1.8 测试代码要保持和线上代码一致，线上有bug，先下线，然后用测试代码在测试环境中测试，改好一处，随时做记录，同步到线上代码
1.9 线上出bug，修复完之后记得总结，包括：原因，紧急性，试过哪些解决方案，以后在遇到这种情况怎么办
一、事故背景与经过
(1) 事故背景
(2) 事故经过，主要包括：
- 事故发生时间
- 事故发现时间
- 事故解决时间
- 线上验收时间
(3) 事故影响范围
二、事故分析
(1) 产品逻辑
(2) 代码逻辑
三、事故原因与解决方案
(1) 事故原因
(2) 解决方案
2. 技术栈方面
-
对于一个技术栈来说，例如hive sql我觉得一定要自己有一个知识框架，这样就算忘了某些知识，只要知道我们的目标，我们就可以在知识框架中去解决
-
对于像kafka、redis以及一些数据库的使用，个人觉得，对于目前所处的任务环境，如果用到了例如像kafka这样的技术栈，要做的一定是搞清楚他们的工作原理机制，以及这个东西怎么去解决当前的问题。至于底层的原理可以暂时先放放，如果有兴趣有时间可以在工作之余去学一学
-
我在开发的过程中，对平时我们所学的数据结构有了更深的理解，明白它的重要性。
具体来说，
(1) 第一次感受到是参加一个会，讨论了课程冲突的代码，当时聊到数据结构的问题，讨论很激烈，知道如果对于数据结构的选取选不好会影响到整个系统的性能，比如存储性能，时间复杂度等等问题。再比如整形数字要比字符串的性能要好一点
(2) 第二次感受到是在自己开发的过程中，由于要设计最终数据结构的存储格式，以方便和后端对接。当时自己接到这个任务是蒙的，完全没有头绪，后来leader给我打了个demo，才发现，哦，原来是这样的。这时，我就思考，在一个项目中，为何数据结构的形式如此重要，发现有一下几点原因：
① 性能问题
② 后端对这个数据结构方不方便操作
③ 数据结构是否可以满足当前的任务需求