Lastor
[工作雜] 真是服了,由於之前堆積了各種問題。現在就連簡單的提一個優化建議,都可以牽扯到一堆有的沒的,莫名其妙一個上午就不見了
Lastor
我們原本有個 API funcA,前陣子修改成需要多帶一個參數 optionA
Lastor
改完之後又因為一些反饋,最後又要把那個 optionA 改掉,變成不用帶
Lastor
因為現在我們很多 API 都改成需要帶這個 optionA,我就怕說會不會之後又改需求,變成又要改 API
Lastor
那既然不知道到底是不是一定要帶 optionA,那何不改成 optional 的,這樣未來管他怎麼改,我們都能應對,就不用浪費時間一直改 source API
Lastor
結果提出這個建議之後,居然牽扯到一堆 543 的問題,討論了一個上午
Lastor
我到後面跟根本也懶得說話了,只覺得為啥可以搞得這麼複雜??
Lastor
心中默默決定,下次還是別提意見好了,提優化建議反而 cost 更高
泉的第一張限定SSR
0.0
泉的第一張限定SSR
一個固定 object 解決一切xd
Lastor
泉的第一張限定SSR : 你是說用一張表去控有 or 沒有的意思嗎?
泉的第一張限定SSR
就一個固定的 object
裡面想改什麼參數就改什麼參數xd
Lastor
喔喔,我聽懂了,你是在說用 object 形式的入參
jsFunc({ argA })
Lastor
如果這段是 js 的那沒問題,頭痛的是,那是 C 那邊的 API
泉的第一張限定SSR
c 那邊其實
有更萬用的方法
但是....
泉的第一張限定SSR
就是用 void * 的 pointer 去傳..
但這被亂用
debug 到天亮xd
泉的第一張限定SSR
a(void* , type)
泉的第一張限定SSR
像這樣
由type去轉型別處理...
Lastor
泉的第一張限定SSR : 啊啊,這個問題不是技術上做不做得到 optional 的問題,而是跨部門的「溝通成本」問題 (眼神死
泉的第一張限定SSR
其實是有更好的辦法解決

只是
我不好說xd
泉的第一張限定SSR
真的好的 ci/cd 工具
一定會跟編譯器的原理有關的
例如 eslint 的 plugin
誒嘿
載入新的回覆