于高衡的技术博客-分享golang、前端、职场、生活琐碎

高效开发的几条建议

高效开发的几条建议
2022-07-16 · 10 min read
后端

不管前端后端,写代码的思维都是相通的,良好的代码习惯是保持高效率的基础,今天来分享几条高效开发的建议,希望可以有所帮助~

学会表达

当你在写一个复杂的表达式甚至需要用到这些表达式来做判断的时候,这时候要养成一个习惯把表达式换成一个变量来表示👀,别人才能语义化的理解你这个表达式。
自己写的代码不管你写的再复杂你自己都可以看懂,但是对于别人不同,如果你把你的这些表达式赋值给一个变量,这样别人只需要知道这个变量是什么意思就行了。

学会复盘

中级与高级的程序员有一个差别是,优秀程序员肯定至少会花一些时间来清理🧹自己的代码。
这么做是因为,他们知道整洁好看的代码比杂乱无章的代码更容易修改,甚至他们知道自己几乎无法一开始就写出整洁的代码🤷🏻。
虽然我自己也没有完全严苛遵守,但是还是希望大家多去复盘,因为当你去看了你之前写的代码后你会发现很多乐趣(觉得自己写的代码可笑🤭)。

拥抱变化

永远都不要说我写的功能 "总是满足我们的需求" ,在做项目开发特别是公共模块,你要学会拥抱变化😥, 永远要考虑变化的情况。
养成一个习惯,在做一个公共模块的时候要考虑后面有没有实现变化的可能或者能不能封装成一个js模块⭕️,而不是直接用第三方库❌。
特别是我们是做客户端而不是简简单单的单页网页,而这里的公共模块指的是 "使用者只用用到你的提供出来的API就知道怎么用了,并不需要使用者去考虑里面的实现"

学会修BUG

很多人在接到一个BUG需求的时候经常只关注 "眼前",即只关注遇到的问题而没有考虑其原本的意义。
你要做的其实不止是修改好这一个缺陷而是要去思考🤔为什么他会出现这个缺陷,一定要关注上下文。
在修改一个旧的模块引发的BUG的时候,我们要保证不影响原来的功能逻辑,考虑清楚再commit,否则就会出现经常遇到的 "改了BUG生成另一个BUG😤"。

多用结构化数据

在你所做的一个组件逻辑很复杂的时候,更要考虑清楚它的结构,多用结构化数据,定义一个数据结构来存储中间状态,而不应该永远用简单的状态❌。
所有复杂的组件你的状态复杂是可以接受的,但是有多个状态是不可接受的。
因为如果明明可以用结构化状态来存储,反而用多个状态组合实现的话,你这个组合关系就很复杂了。
确定一个你所需要的数据结构,所有的操作都以这个数据结构为目标,这个数据结构可以是一个对象可以是一个数组任何你期望的值,这样最后只需要拿到这个结构化数据来进行简单处理,所有的问题都迎刃而解了。

不要怕错

很多人包括我自己在进入一个新的公司或者面对一个别人正在开发的项目难免都会有一个问题:"不够自信"。
在看到别人的代码时候难免会看见别人明显的错误,而在当下你看来可能对自己编码不自信而不愿意帮忙改正,又怕改了之后被同事责怪,但这是不对的❌。
不要怕改错代码,如果在当时看到一个错误或者命名不规范而你觉得有更好的名字或者重构方法可以及时改正,就算是改错了那就在CodeReview的时候提出来让大家提建议。
这样在下次见到这段代码时就不要重复努力搞懂逻辑,因为很可能下次还会是你继续改动这个模块。

每次只关心一个上下文

如果某个模块经常因为不同的原因在不可预知的方向上发生变化,那么这个模块就变的很散乱了。
当你需要在原有基础上根据一种条件新增功能的时候,我可能需要更改三个函数,两个变量,这样的话就会很烦躁了,在如今这么内卷的时代再烦躁起来得有多难受😥。
我们要养成一种习惯每个函数只干一件事情,将一个功能按照不同模块划分开来,分成数个上下文而每次我们修改功能的时候只需要找到对应的模块来修改就很清晰了,我们只需要关注那一个上下文就可以了。

消灭注释

尽可能少的添加注释,特别是团队开发,有很多人不理解为什么?🤔我举个最简单的例子:如果这个函数以后功能变了,除了我们需要改里面的代码还需要帮忙改变函数命名还要一起把之前的注释也改了,假如一个函数有5-6行注释这么多,那你是不是每个都要改?
当然在不添加注释的前提下我们要保证我们函数命名变量命名尽可能语义化👌🏻。
任何你觉得需要注释的地方,99%是因为这段代码不合理。
每当你需要用注释来说明什么的时候,我们要做的不是用文字去解释这段代码,而是把我们需要说明注释的东西写进一个独立函数,并以它的用途取个语义化的名字✅。
甚至我们可以用短短几行的小函数来代替这件事情,哪怕之后调用函数的步骤变多,但是只要每个函数命名足够语义化,就能用代码合理的解释你想要做的一切。
函数的长度关键不在于有多长而是在于可读性,在于"🤨如何做"和"🥴做些什么"。

不畏注释

我们通过上面的方法可以有效的减少在代码内的注释但是对于别人已经遗留的注释我们应该置之不理吗?
如果在修改的功能模块发现原来存在注释,不要去抱怨,这对你没有一点好处,相反的这可能是个很好的信号去告知我们应该去对这段代码进行修改,而通过这些注释可以精准的帮我们定位到他的问题所在。

学会命名

如果在编写一个函数的时候你无法对其进行命名,那么这个函数多数是设计不合理的,就像我们上面提到的,函数里面表达的是 "如何做"和"做些什么" ,而我们对函数的命名也切记按照这个原则。
当你真正对一个函数准确命名,那么这里面的结构往往是可读性高的。
做任何业务都不要把实现写在函数名上,以后如果别人需要改动函数逻辑,还要帮你把函数名字给改动了。

合理入参

对于携带参数的函数的命名也是有讲究的,我们通常可以使用通用的名字来代表参数命名而不是使用在当下具体的名称,比如:apiSelectedKey=>selectedKey
修改的好不仅能增加函数的应用范围,还能改变连接一个模块所需的条件,从而去除不必要的耦合。

学会提炼函数

在简化代码块的时候,我们最喜欢的就是提炼函数,提炼函数可以让我们将意图与实现分开。
并以意图命名函数,但是如果发现自己并不能合理命名,说明你不应该提炼这个函数😵‍💫,你应该考虑更多。

学会返回

上面讲了两个关于函数命名的方法,而往往在小函数内我们对于内部的变量会 "词穷"。
大部分的函数都可以使用result作为返回值,在函数开头定义,在函数结尾return,这样下次看这段代码的人一下就知道要返回的是什么🧐。

考虑时机

往往我们刚拿到一个新需求的时候很容易去实现它的功能,甚至不会去调研,修改BUG也是如此。
这是很容易的,任何一个程序员都可以做到,但是在什么时机做这个 "动作" 是应该考虑清楚的,点击的时候?依赖变化的时候?函数返回的时候?
我就吃过这个亏,在不恰当的代码恰好完成了需求但是引发了一些不可控的缺陷,导致我要重复读这整个模块的代码,不仅拖慢了项目进度还让自己多掉了几扎头发🧑🏻‍🦲。

保持可拓展性

在拿到一个新需求的时候永远永远不要想着做完就ok,因为你无法保证以后会不会让你在这个基础上增加新的功能甚至在你commit后的一个小时,产品的需求如果你没有优秀的产品思维是捉摸不透的😭,所以要给自己留 "一条后路"。
而这* 而最常见的无非就是各种判断,根据不同的判断来让程序走不同的代码,这时候我们不能写死判断而是多去使用map结构来保持功能可拓展性😎。

巧用模块

如果你发现两个模块之间需要交流,或许你可以新建一个模块📦来存放。
在做一个需求的时候,如果很多函数跟变量都是从不同的第三方库引入,这时候不妨把它归为一个模块,就算是函数变量名字一摸一样都可以。
只要保证是在这个模块里面导出就可以,这样后面的人更加方便维护这个模块,屏蔽这个实现。
使用的人不关心用,只关心结果,就类似中间层🆗。