开发经验贴（持久更新）

[chaseFunny]

背景

开发中，总是会犯错，或者发现之前的行为效率低下，于是打算写一篇，记录日常开发的总结经验，闲下来再拿出来看看，不断优化开发习惯，让自己更好

记录

无论再急 ，pr 一定要自己先过一遍

不浪费别人的时间，是对别人最大的尊重

做重复的事情，一定要小心

做重复的事情，99%都会交给惯性来操作，大脑会停止思考，但是这非常危险，这时候应该更加打起精神，因为问题最容易发生在这时候，而且要思考这种重复的事情是否可以交给机器，因为机器（技术）要比人靠谱的多

处理 url 的时候，最好使用 encodeURIComponent

当我们在路由参数处理的时候，最好使用 encodeURIComponent 来保证参数传递正常，或者在对接第三方 SDK 的时候，需要注意第三方提供的文档中是否标注需要对 url 进行编码

魔法值

开发中避免直接使用 0 1 2 这种数字，应该定义一个语义化枚举，来映射具体值，提高代码可维护性

对于特殊逻辑，一定要写注释

在实际业务开发中，肯定会有一些看起来很奇怪的逻辑，这时候需要编写注释，来方便后面维护的人理解

边界处理

写完代码后，要思考不同场景，“防御性编程”

重复的事情最好交给代码

如果一件事需要重复做，那么就最好将其抽象为工作流，然后通过程序来实现，或者实现一部分

验证代码正确性比什么都重要

当完成功能，需要进行验证，这比更快上线功能重要

注意 local 和线上环境不一致

当我们在本地开发的时候，发布线上一定要查看本地的环境，配置，依赖包版本和线上是否一致。如果可以 build 查看，一定要 build 检验，否则导致线上问题问题就变严重了

当修改公共组件，模块，函数。需要充分测试使用的地方是否都是正常

前后端联调的时候，尽量做到获取数据最最少原则，不要获取多余的数据

面对不确定的，高复杂的，先确认，做好设计，再进行开发

如果一个组件，某块打算抽离出来，就要尽可能的通用，要和业务解耦

举个🌰：阿牛开发了一个类似语雀左侧支持搜索的文件夹结构，那么这个可能以后在很多地方使用，那就打算抽离为公共组件，那就需要考虑如何更加通用，例如：它接受的就是搜索词、树形数据。把如何获取数据、如何通过搜索词更新数据的逻辑都要放在业务端，组件仅仅负责接收数据，展示数据，接收用户输入，然后返回搜索词给业务端，让业务端来处理搜索

如果在小公司，要确认是否需要做调研

例如，让阿牛区开发一个评论区功能，然后样式参考别家就好，那这里就需要确认是否要做需求调研，是简单参考还是要写文档做确认再开发，否则会出现开发完成，却不合格，一直说有问题

尽量避免写死数据

举个例子，当我们要计算一个列表中某个元素相对父元素的y轴顶部距离，我们知道每个列表项的高度是多少，但是我们最好通过 js 获取它的高度，而不是写死列表项的高度

最好先搞定数据，再搞定逻辑，最后再开发页面

当我们面临复杂功能，最好先梳理好我们要完成的 js 逻辑，然后将逻辑拆解为一个个小的好做测试的函数，当我们完成所有 js 逻辑和测试后，再去写页面就会非常简单

避免数据冗余和状态重复

在开发中，要尽力避免数据的冗余，例如：定义了商品的单价，数量，那商品的总价就可以计算出来，是可以通过函数计算的。而不需要再声明一个变量来存储，而是创建一个函数返回商品总价。这样避免数据的冗余，也能避免代码逻辑混乱。

React 开发中，也要保证声明的状态是最少的，不要声明不需要的状态

如果一件事情很复杂，第一个想的不应该是怎么解决它，而是想能不能不要它

举个例子：我在做一个以图搜图的功能，我打算使用百度的以图搜图能力，我发现请求接口需要几个参数，其中有一个是 sdkParams ，它的值是动态的，我里面想着这个动态的值是哪里来的，但是我应该去尝试不要这个值是不是依然可以跑通流程，事实就是确实不需要它也行，但我掉进了陷阱，导致浪费了时间

如果在开发公共模块，一定要多测试

开发完成，看看使用到公共模块的地方是否都还正常

上传功能要做资源限制，资源压缩等优化措施

这里我个人理解资源优化不应该在前端做，应该在后端，或者中间件来处理

是否能清晰知道逻辑应该放在前端还是后端

初级开发可能会分不清什么逻辑应该后端做，从而导致前端有一些混乱的逻辑