韌體工程師的悲哀

我在公司是打雜的。是IT，也是應用軟體工程師。在軟體方面，信奉的是軟體工程、軟體方法論。

今天要談的就是”韌體工程師的悲哀”

一般來說公司的韌體工程師非常重要。在台灣，學韌體通常被要求懂硬體，才能被認定夠格，或甚至強不強的指標。

寫韌體的工程師也以此為目標自我激勵，希望成為公司裡面偉大且獨一無二，公司不可或缺的人物。韌體工程師一旦走人，程式將可能面臨找不到人接手，下場悲慘。

我想說的是在上位者鮮少有人認為韌體工程師需要懂軟體工程，這樣非常危險。

我舉兩個對比例子解釋一下

(一)

有一個韌體工程師能力超強，他用C語言寫了一個10000行的程式，完成了某項產品。

後來公司要求產品能夠改用便宜主要晶片，這時候該韌體工程師就頭大了，因為這10000行程式，裡面有非常多的寫法直接對硬體存取，導致修改非常困難，只好告訴公司, 需要非常多的時間處理。

有一天該韌體工程師離職了，公司高層跪拜數次挽留未果，招了一個技術能力強的人來，但看不懂前人的程式，裡面有著太多硬體相關程式碼，非常難以理解，人就跑了，或是花更多時間修修改改，甚至打掉重練，公司最慘就只能放棄治療。

(二)

有一個軟體工程師不懂硬體，在公司不諒解的情況下(無法一條龍甚麼都懂)，指定一位硬體工程師跟這軟體工程師搭配，最後也完成了某項產品。

後來公司發現，這個軟體工程師，設計了「硬體存取介面」，也輔導硬體工程師撰寫該硬體存取介面。

對硬體工程師來說，只要專注寫硬體存取介面，其實也不難，寫得也開心。

而這個軟體工程師，撰寫韌體，但是他的韌體中的所有程式碼，都不直接存取硬體，不會有讓人看不懂的硬體獨特語法，而且藉由呼叫硬體工程師寫出來的存取介面，讓人更能了解程式架構。

後來公司要求產品能夠改用便宜主要晶片，這時候該軟體工程師告訴硬體工程師，再寫一份便宜晶片的硬體存取介面，經過適當的參數調整，很快就完成任務，整個程式只要修改5~10%，而且能成功。

有一天該軟體工程師離職了。公司招了技術能力夠的人來上班，看了看程式，發現程式簡單易懂，不會有艱澀難懂的硬體存取寫法，新人很快就上手，而且新人又開發一個能夠模擬”硬體存取介面”的機制，在無硬體情況下，就能直接透過連續整合(CI)進行方式測試；此舉也解決”要有樣品才能測試，且測試緩慢無效率的問題”。

韌體工程師的悲哀在於：他們認為(或是被認為)甚麼都會(Layout、HW、FW、SW)，就是最強。

事實上軟、硬體工程師們，在這個世代，環繞著資訊安全、前端、後端、雲端、軟體確效、物聯網，還要懂各式各樣的通訊協定，認同測試為品質保證的不二法門，最後一起協同合作才能完成任務!

過往英雄單打獨鬥已不可行，就算可行，也只能局限於小格局啊。

以下連結，很唬爛，會誤導工程師；有些想法危險，千萬不要用在現在這個世代。

舉個例子來說，很多有名的開源案子，誰能獨當一面獨立開發？誰能1人抵20人？
開發人員該驕傲的是程式能大家一起討論，一起變強，而不是在強調個人能獨立優化了3000行，別人卻做不來，並且沾沾自喜四處宣揚。

github最大的成就就是讓所有人也一起成長享有榮耀!