highlight: obsidian theme: cyanosis
前言
Array 跟 Object 两兄弟的故事告一段落了，接着是 Object 在外面养 (?) 的另外一个兄弟 - function
浪漫一点来说，function 其实就像是另一个平行宇宙，从 function 的呼叫处一跃而下，穿越虫洞到了另一个与世隔绝的小空间，而在这个空间发生的事、定义的变数，(基本上) 不会影响到原来的时空。
所以我称进入 function 是一场「时空旅行」，好啦可能时间还是照常流动 (同步)，不过起码空间是换了一个 context。
今天我们先来聊聊，要进入时空旅行之前，总是要带一些干粮或行李，我们把它称作：
✅ 参数优化
蛤？function 的参数太基本了吧！呼叫的时候一个一个丢进去，使用的时候一个一个取出来，同学你不是来骗赞的吧！？
嘿啊，我也知道 function 带参数是基本中的基本了，所以这个问题应该改成：
参数怎么带比较「好」
✔ 参数一个一个带会遇到的问题
我们举个例会比较清楚：
// 查询网银交易的纪录 /*\* userId : 使用者 id\* startDate : 查询区间开始\* endDate : 查询区间结束\* searchKeyword: 搜寻备注关键字\* type : 'deposit'(存款) 或 'withdraw'(提款)\*/ const queryTransaction = (userId, startDate, endDate, searchKeyword, type) => { // 实作到 DB query 资料的部分 }; queryTransaction('612b06609ea3b35614c0edbd', '2021-09-16', '2021-10-15', '同事代垫', 'deposit');上面的例子可以看出，当一个 function 的带入参数很多时，很容易会遇到这些问题：
呼叫时，看不出每个参数各自代表什么意义，需要跑到 function 定义的位置才知道。
某个参数是选填时，如上例，如果使用者不想特别「搜寻备注关键字」，就还得刻意填个 null 之类的。
函式定义如果要修改参数的顺序，就要把所有用到这个函式的地方改过一次。 ✔ 参数过多就组成 Object 传进去吧
稍微改进一下会变这样：
// 查询网银交易的纪录/* * userId : 使用者 id * startDate : 查询区间开始 * endDate : 查询区间结束 * searchKeyword: 搜寻备注关键字 * type : 'deposit'(存款) 或 'withdraw'(提款)*/const queryTransaction = ({ userId, startDate, endDate, searchKeyword, type }) => { // 实作到 DB query 资料的部分};queryTransaction({ userId: '612b06609ea3b35614c0edbd', startDate: '2021-09-16', endDate: '2021-10-15', searchKeyword: '同事代垫', type: 'deposit'});如果是上述的版本，因为是带入一个 object 当作参数
我可以帮每个参数「命名」，就可以知道每个参数代表什么。
object 内的 key 是没有顺序性的，所以即便我把 userId 搬到 type 的后面，也不用去改函式呼叫的地方。
如果我今天不想要「搜寻备注关键字」，那就直接不要带这组 key/value 即可，完全让它变成一个 optional 的选项，不用特地 null。
以上三点就把刚才上面提到的三个问题都解决了，变成更有弹性，且即便后人接手 refactor，也比较不会因为参数的增减、顺序而造成 bug。
✔ 再优化！必要参数与选填参数区隔开
可以想像我现在是带着一个后背包出门，里面装了我所有的旅行用品，但外表看起来就是一个后背包，所以里面少带了什么其实不一定会发现
所以我们把后背包里面，比较重要的东西拿出来握在手上，告诉自己一定要手上有东西才可以出门，有点像是出门先喊「手机、钥匙、钱包！」一样
因此这边可以再做一个小优化，因为上述提到的三个问题，都比较是因为参数过多，而且有一些其实是选填参数所造成的。
因此我可以只把选填参数包成 object，而像 userId 这种肯定是必填的栏位，要避免其它同事不小心漏掉，就可以直接用原本的方式放在前面：
const queryTransaction = (userId, option) => { const { startDate, endDate, searchKeyword, type } = option; // 实作到 DB query 数据的部分};const option = { startDate: '2021-09-16', endDate: '2021-10-15', searchKeyword: '同事代垫', type: 'deposit'};queryTransaction( '612b06609ea3b35614c0edbd', option);参考其它套件的类似做法
用fetch发送 request 的时候，必要的栏位是 URL，其它都放在 option
const fetchOption = { method: 'POST', body: JSON.stringify(data), headers: { 'user-agent': 'Mozilla/4.0 MDN Example', 'content-type': 'application/json' }};fetch('这里是 URL', fetchOption) .then(response => response.json())用mongoose连线 DB 时，必要的栏位是 URL，其它都放在 option
const mongooseOption = { ssl: true, autoIndex: true, serverSelectionTimeoutMS: 5000,};mongoose.createConnection('这里是 URL', mongooseOption);✔ 不要修改带入的参数
没错，时空旅行就是单纯去旅行就好，背包里的行李不要变质。。。
翻成白话就是，「不会有任何一个参数，会因为执行了这个 function，而产生任何变化」。
这是之后会提到的 Functional Programming 的其中一个重点，也就是避免像下面这种 side effects：
const arr = ['Jack', 'Allen', 'Alice', 'Susan'];const sortArr = () => { arr.sort();};console.log(arr);sortArr();console.log(arr);执行结果['Jack', 'Allen', 'Alice', 'Susan']["Alice", "Allen", "Jack", "Susan"]这种状况通常会在 function 最开头，先把参数拷贝一份，然后用拷贝的资料来修改，保持正本 read-only：
const arr = ['Jack', 'Allen', 'Alice', 'Susan'];const sortArr = () => { const copiedArr = [ ...arr ]; copiedArr.sort();};console.log(arr);sortArr();console.log(arr);执行结果['Jack', 'Allen', 'Alice', 'Susan']['Jack', 'Allen', 'Alice', 'Susan']这个问题只会出现在参数是 non-primitive 的时候。
因为如果是把 primitive 变数当作参数，会是call by value的方式，丢一个拷贝后的副本进去 function，不管怎么改都不会影响到正本。
而 non-primitive 则是call by reference，会直接把正本丢到 function 里面，如果改了就会连带影响外面。
主要是为了避免不可预期的 bug，因为如果每次执行这个 function 都会造成外面的变数变化，那代表如果这个 function 出现问题写错了，就会造成其它地方也着火，到时会很难厘清问题点到底在哪，对于 unit testing 也是相当不利的。
不要修改带入的参数的例外
前面提到，不要修改参数的原因是怕「不可预期」的状况，反之，如果是「可预期」的，那么直接修改参数其实是效能更好的哦！
最常见的例子就是前两天介绍的彻底掌握 Array（一） reduce，当初要做「Array 转换成 Object」的例子时，就直接塞新的 property 给 reduce 内的那个 prev (第 7 行)：
const arr = [ { id: 'item1', name: 'TV', price: 13500 }, { id: 'item2', name: 'washing machine', price: 8200 }, { id: 'item3', name: 'laptop', price: 25000 },];const resultObject = arr.reduce((prev, curr) => { prev[curr.id] = curr; return prev;}, {});console.log(resultObject);可以直接进行参数修改的原因是，reduce里面的这个 function，本身是「可预期的」，因为我们已经把初始值定为{}，所以不管这个 reduce 执行多少遍，里面的 function 都是从 {} 开始跑，永无例外。
在这种非常确定可以直接修改的情况下，「直接修改」比起「先拷贝再修改」的效能还快得多，因为拷贝本身真的很吃效能 (尤其 deep copy)，有兴趣可以参考这篇，有实测数据可以参考。
结语
function 的参数，简单可以很简单，难起来居然也像这样可以独立一篇出来讨论了！
但无论如何，今天讨论的都不是如何把程式写「对」，最上面第一块程式码区块，就已经是可以正常运作的了。
差别只在于，如何在运作正确之余，让程式规模更容易扩充、除错，这些都将是未来设计更大、更复杂程式会遇到的难题。