在好未来实习了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,才发现,哦,原来是这样的。这时,我就思考,在一个项目中,为何数据结构的形式如此重要,发现有一下几点原因:
① 性能问题
② 后端对这个数据结构方不方便操作
③ 数据结构是否可以满足当前的任务需求