學到的東西

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

• 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 年！