iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 30
0

學到的東西


既然是最後一篇的總檢討,當然不能列出之前就已經學會的部份。這裡列出的,全部都是這三十天之內累積起來的內容:

  • RISC-V
    • 使用 virtio 版本的 qemu 當作模擬器
    • 對於 I 指令集熟悉到幾乎背的出來
    • 每一種指令型態的格式
  • GO 語言
    • 許多函式庫的用法:debug/elf、encoding/binary、json
    • map 和 slice 的用法
    • 開始嘗試從 riscv-go 這邊的 porting 加入實質的開發(參考連結
  • ELF 檔案格式
    • 雖然之前有硬啃過一次規格,但是開始做之前全部都是假的,只有開始做了之後才成為身體記憶
    • 區段的概念、標籤、重定的概念

檢討


筆者在過程之中一再動態調整規劃,卻也一再拖延。幾點重要的感想,條列如下:

  • 標準需詳讀:在處理標籤相關內容的時候,在這裡吃了大虧。有些標準至今看來還是非常的不合理,但實在是不知道有誰能夠討論這件事情?比方說,為什麼會需要空的區段標頭?為什麼需要空的標籤?為什麼重定區段又不需要第一個元素是空的呢?但是很現實的就是,一旦標準不對,根本就沒有辦法使用,更不用說後面的驗證和運作了。
  • 應該理解的更清楚之後再動手:不得不說這是後進者的劣勢。先驅如 GNU 已經發展了很久,而且過程中有很多回饋自身的設計理念和方法,以及當時代的偉大靈魂的各種腦力激盪,以至於現在即便形成了一道有時令人感到醜陋的高牆,它的設計可說是千錘百鍊。所以,如果以挑戰者自居,至少要了解的越多越好。以這個系列文為例,當我第一次被迫因為發文的時限壓力而犧牲實作框架的美感之時,就只能繼續疊床架屋下去,到頭來儘管 GNU 用的是 C 而我用的是更容易寫且功能更強大的 go,我還非常微小的 codebase 就已經讓我頭痛萬分。如果能夠重來,我當然能夠做得更好。
  • bug 與測試:在過程中偶爾提及我想要拿 go 語言的測試框架出來使用,但最後都沒有。這其實和上一點有點類似,這些讓軟體專案能夠更強韌的原則最後都拿去換時間了。雖然上傳到 github 的程式是可以動的,貼在文中的程式碼片段卻往往都有 bug,這是因為我通常在第一版寫完之後就直接更新到文章裡,但最後都會有一堆 bug 要修正。這與我個人對 go 語言的不了解、對 ELF 的不了解有關,但顯然能夠幫助提昇軟體品質的測試這一環卻一直沒有引入。有點遺憾。
  • 太過樂觀:事實證明,所有的規劃全部都延遲了,而且延遲的幅度幾乎可以說是乘以二才差不多的地步。未來也許這樣具野心的專案,這方面不可以太樂觀。

結語


這個系列真的是筆者挑戰極限之作,雖然程式碼的品質實在是連自己都看不下去(重構確定!),但是以這個極限的進行方式,真的已經是無愧於心。也很感謝讀者諸君的監督,無形的力量讓筆者始終鞭策著自己,渡過台面上的生活的每一刻,秉持絕對不卡文的精神顢頇地挑戰鐵人賽的道路。這段期間筆者甚至經歷了許多大事件,跨年、公司新人報告、甚至這幾天還大病一場,終於是挺過來了。

除了感謝讀者之外,也感謝兩肋插刀的同事。顯然我們身為工程師、技術人,對於自身技術的成長總是相當嚮往,但雖說如此,要一口答應一個認識沒有幾天的新進人員的這種 30 天的試煉邀請,他們仍然是相當令我感動。

HelloWorld君的系列跟筆者一樣是與 RISC-V 相關的主題。一方面是因為這個新的計算機架構具有電腦史上前所未有的開放度,二方面當然就是因為公司重點經營這方面的業務,在公司努力創造價值製造利潤之時,我們個人當然就順勢精進技術,並且貫徹開放的精神將所學透過技術文章的方式分享出來。H 君文筆生動許多,不像筆者這般生硬,每天也都很認真思考怎樣的標題才夠有梗;與除錯相關的內容更都是第一手資訊,希望大家會喜歡。

nylon君的系列則是較熱門的機器學習主題。N 君日常業務跟這個主題八竿子打不著邊,但是由於先答應了筆者要參與,後來在開賽之前反覆苦惱著到底應該選擇什麼樣的主題。他在公司的桌上有一本比演算法聖經本還要厚的 Computer Systems,那原本是比較符合他所擅長的領域,他也可以以讀書筆記的方式進行。然而他後來選擇了另外一條充滿荊棘的道路:從 0 開始聽線上課程的機器學習內容,他本人也在這段期間累積了許多機器學習的知識並用心的整理出來。歡迎大家參考他的系列文。

無論如何,今年的鐵人賽也順利來到終點了。祝福各位 IT 人都有個美好的 2018 年!


上一篇
第二十九日:as 強化(下)
系列文
與妖精共舞:在 RISC-V 架構上使用 GO 語言實作 binutils 工具包30

尚未有邦友留言

立即登入留言