跳到主要內容

Fred Chien 關於工程師成長的思考

現在回想當年的狀況,發現當時是自己連問題在哪都不知道,基礎能力相當薄弱。縱使能夠寫大量的程式、熟悉不少常見的演算法與技術、也能把想到的功能都刻出來,但事實是連問對正確的問題都沒辦法,理所當然也不會得到正確的解答。

不過幸運的是,大概是高中低階技術和各種場景接觸多了(渾渾噩噩也經歷了五、六年),縱使也不是多厲害的專家,某一天開始感覺到開竅,似乎對很多當年從未想過、從未理解過的關鍵問題,不知不覺想通了。開始意會到當年系統架構設計的問題在哪裡、可改善的方向、程式該如何重構。

很多事沒有機運、沒有想過,就不會貫通,也無法想的深遠透徹。即使靠大量的單調無腦的苦練,成為了踢一萬次腿的鐵腿神,仍然無法得到突破。單論自己以一個後端工程師的生涯來說,經歷了近十年跌跌撞撞,才赫然發現自己剛踏出了 junior 的領域而已,得到了第一次的變身。

留言

這個網誌中的熱門文章

Git 注意事項

使用 Git 的一些技巧 1. git pull 的時候可以用 --rebase 比較不會有多餘的 merge point 2. 善用 squash commit,squash 完心情都很好 3. commit 之前一定要先 format code 一次,不然多出來的 reformat commit 會很難整理 4. 拆 commit,盡可能讓每個 commit 都可以 build & test,也比較好回到上游 5. 如果 local 修改的整理過的 commit tree 要 rebase 上去就只能用 rebase onto e.g., git fetch upstream git checkout -B local-rebase-branch upstream/feature/binance-futures git rebase -i upstream/main .... 改改改 git push -f origin HEAD -B 會洗掉原本就有的 local branch CS Visualized: Useful Git Commands Code Cleanup: Splitting Up git Commits In the Middle of a Branch Git rebase --onto an overview 30 天精通 Git 版本控管

上市的概念

傳統上市流程繁瑣,合規要求門檻太高.. 如果今天只是某個在 Github 上的早期小項目,可不可以直接發幣呢? 發 PR 賺 token ; 發 Issue 出 token (沒有就去交易所買) 利用設計精良的 Token Economic,透過 DAO 之類的方式,可規模、可持續地 distribute token,看需求再 IEO、IDO 等等,感覺會很有趣! 像是把 VC 的概念簡化,希望能讓軟體工業回到“員工股票分紅費用化”以前的年代。

三種資料

  成交前:      OrderBook 上有交易所所有的掛單資料      理論上最好的成交價格 midPrice = (bestAsk + BestBid) / 2 成交時:     Trade Price, Volume ... (Tick Level)      Trade Price 是實際上的成交價格     用法: trade.price 成交後:     根據 interval,累積一段時間的 Trade 資料,有兩種:          1. onClosed()           2. 即時 Stream      用法:kline.close 資料來源可能是 stream 也可能是 web api  , 看各交易所實作的情況 (註記:理論上所謂的成交前狀態應該不存在,那是薛丁格的狀態) 更新:Tick period = average time between changes in the mid-price. Tick 事件有三種可能的發生原因:     1. "BID" (one side is LO)     2. "ASK"  (one side is LO)     3. "TRADE"  (one side is MO, both sides are MO, two LO at the same price) 當 mid price 發生改變的狀態,一定會 emit tick event 更新:這邊的 tick 是 mid price 的話,那要 best bid/ask 改價格才會變動。 撤單下單在 best bid/ask 範圍區間內都會影響! trade 把best bid/ask taken away 那也會影響! 但是假如 trade 不夠多,tick還是不變的!