☀️ 前言
- 从去年入职
Apifox
研发组至今,已经有快四个月的时间了,今天来跟大家分享一下我的感想💭。 - 写这篇文章的契机是在年后我成功通过三个月试用期,也算是给自己一个交代,从自身出发来进行反思与总结在这三个月学到的东西与一些感想✍🏻。
☃️ 我学会了什么
- 在这三个月内我更多接受到的是工作或者说是写代码甚至作为程序员应该掌握的方法,而这些方法不在于你是什么技术栈或者说什么职位都很有用🤓,所以今天我就来分享一些我总结的
30
个方法,我主要分成💻代码方面
和💻程序员方面
。
💻 代码方面
学会表达
- 当你在写一个复杂的表达式甚至需要用到这些表达式来做判断的时候,这时候要养成一个习惯把表达式换成一个变量来表示👀,别人才能语义化的理解你这个表达式。
- 自己写的代码不管你写的再复杂你自己都可以看懂,但是对于别人不同,如果你把你的这些表达式赋值给一个变量,这样别人只需要知道这个变量是什么意思就行了。
学会复盘
- 中级与高级的程序员有一个差别是,优秀程序员肯定至少会花一些时间来清理🧹自己的代码。
- 这么做是因为,他们知道整洁好看的代码比杂乱无章的代码更容易修改,甚至他们知道自己几乎无法一开始就写出整洁的代码🤷🏻。
- 虽然我自己也没有完全严苛遵守,但是还是希望大家多去复盘,因为当你去看了你之前写的代码后你会发现很多乐趣(觉得自己写的代码可笑🤭)。
拥抱变化
- 永远都不要说我写的功能 “总是满足我们的需求” ,在做项目开发特别是公共模块,你要学会拥抱变化😥, 永远要考虑变化的情况。
- 养成一个习惯,在做一个公共模块的时候要考虑后面有没有实现变化的可能或者能不能封装成一个
js
模块⭕️,而不是直接用第三方库❌。 - 特别是我们是做客户端而不是简简单单的单页网页,而这里的公共模块指的是 "使用者只用用到你的提供出来的
API
就知道怎么用了,并不需要使用者去考虑里面的实现"
学会修BUG
- 很多人在接到一个
BUG
需求的时候经常只关注 “眼前” ,即只关注遇到的问题而没有考虑其原本的意义。 - 你要做的其实不止是修改好这一个缺陷而是要去思考🤔为什么他会出现这个缺陷,一定要关注上下文。
- 在修改一个旧的模块引发的
BUG
的时候,我们要保证不影响原来的功能逻辑,考虑清楚再commit
,否则就会出现经常遇到的 “改了BUG
生成另一个BUG
😤” 。
多用结构化数据
- 在你所做的一个组件逻辑很复杂的时候,更要考虑清楚它的结构,多用结构化数据,定义一个数据结构来存储中间状态,而不应该永远用简单的状态❌。
- 所有复杂的组件你的状态复杂是可以接受的,但是有多个状态是不可接受的。
- 因为如果明明可以用结构化状态来存储,反而用多个状态组合实现的话,你这个组合关系就很复杂了。
- 确定一个你所需要的数据结构,所有的操作都以这个数据结构为目标,这个数据结构可以是一个对象可以是一个数组任何你期望的值,这样最后只需要拿到这个结构化数据来进行简单处理,所有的问题都迎刃而解了。
不要怕错
- 很多人包括我自己在进入一个新的公司或者面对一个别人正在开发的项目难免都会有一个问题: “不够自信” 。
- 在看到别人的代码时候难免会看见别人明显的错误,而在当下你看来可能对自己编码不自信而不