[請益] 1~3年韌體工程師求前輩指點

[zzss2003 (brotherD)]

嗨，今天大家過的好嗎。
小弟寫FW已經有一兩年了，大概了解這個領域的工作內容以及涉及的範圍。目前技術能力
卡在一個瓶頸，想上來請教各位大大該如何精進自己。


先說說我已具備的能力。

1.有辦法讀懂OS手冊，並正確使用該API。

花了兩個月把uC/OS-III的手冊看完一遍，且成功使用semaphore與message queue。有辦法
融會貫通手冊想要表達的觀念以及kernel的實作細節。但僅止於此，就是會用而已。

2.有辦法快速上手新的硬體，並寫出該硬體的driver。

3.其他抓硬體bug，用示波器...blabla的基本能力就不贅述了

目前欠缺的能力

1.物件導向的觀念

我發現我之前寫的code在亂寫，很像是把一堆東西東湊西湊然後混著用。我希望自己能寫
出具有模組化的程式碼，且有辦法在未來需要擴充的時候不用牽一髮而動全身。
上網查，如果在C語言加入物件導向的觀念，可以改善這部分(請幫舉證?)，所以我最近試
著想要用C語言的角度了解、寫出物件導向的程式碼

但我找不到一本好的入門書，請各位網友建議，謝謝。

2.欠缺讀code的能力

當coder把user用不到的資訊全部放在header file，會讓user越讀越混亂。好的code應該
具有information hiding的特色(我自己說的)，

我沒辦法在一堆混亂的資訊中過濾出有用的資訊，並且了解對方在寫什麼。看到會讓人誤
會的變數命名、沒有註解的function prototype、沒有意義的檔名以及沒有把每個file分
層的project，我真的必須要一直問對方才有辦法了解對方的邏輯。

我知道可以要求對方多加點註解，或者是要求改善他的寫法。但我相信我更應該做的是提
升自己的閱讀能力，而不是去要求別人。想請問這部分需要如何提升自己呢?

3.程式組織能力

這部分有一點抽象。比如在寫一支application，我可能會自定義很多型別(struct)，但我
發現我有時候會搞錯各個成員(member)該擺放的位置，比如A結構的成員我可能會放到B結
構裡去，導致在寫struct of struct的時候會卡住。

常常搞混type的命名與identifier的命名。
拿int number做比喻好了，我們很清楚知道number的型別是int，但我有時候就會命名成相
反。該怎麼說呢，就是有點還沒辦法明確地分清楚各個struct要擔任的角色，以及type的
定義嗎?(我自己也不知道問題出在哪)

這部分我目前不知道該怎麼辦，感覺搞懂物件導向後有辦法改善? 還是看資料結構?(我買
來但都沒時間翻)

4.無法明確掌握自己該精進的方向

比如最近看到一個網址: https://www.state-machine.com/

它好像在提倡它的工具比RTOS好用，什麼framework還有state-machine的，還加上UML。
我腦袋就出現一堆問號，諸如:

什麼是UML?
在RTOS的環境下沒辦法寫state-machine嗎?
RTOS跟它的framework不能共存嗎?感覺是同一種東西啊!...blablabla

這些問題我也有上網google過，但也只能懂表面，沒辦法了解他們在幹嘛


希望有位好心的大大可以跟我聊一聊Q_Q讓我知道我目前在roadmap的哪裡，以及該怎麼前
進，謝謝!(如果打的很亂請見諒)

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.216.18
※ 文章網址: https://www.ptt.cc/bbs/Tech_Job/M.1548137551.A.849.html
※ 編輯: zzss2003 (118.163.216.18), 01/22/2019 14:21:03
→ kain777: 你完全搞錯方向= =
→ ggBird: c的物件導向去看 linux碼, 一堆都是或是jserv有教學影片
推 trink: 問題1~3，可以看clean code/clean architecture
推 owenais: 了解設計模式，及多看code 會有幫助
→ i386: 第1點怪怪的，uC/OS-III需要自己實做semaphore和message que
→ i386: ue? OS本身就有這功能吧
打太快，以更正
※ 編輯: zzss2003 (118.163.216.18), 01/22/2019 14:47:11
噓 LinuxKernel: 第一句聽到有點煩
噓 leonEEman: 你可以去問油土伯
→ i386: 讀code能力，除非自己有毅力去找open source的專案慢慢看裡
→ i386: 面code, 不然就是接一堆幫人擦屁股的解軟體bug的工作來做
推 i386: 韌體的話，建議你站穩一塊domain knowledge,ex:USB, TCP/IP,
→ i386:  File system....這是做韌體最核心的價值
→ loadingN: 吃飽太閒可以去trace Linux kernel啊
推 su27: 1.的話就是指標+strict,就差不多能用了
→ su27: Struct
推 ahlolha: linux下面不同的subsystems很多都有搭物件導向寫法
推 vul3kuo: C不是物件導向語言 不需要完全用物件導向
→ vul3kuo: 硬要用C寫OO 可讀性會很差
推 csfgsj: FW code 扯進 OO 就完了
推 xu3fu6xup6: youtube搜尋
→ xu3fu6xup6: 你所不知道的c語言
推 Hack: 寫FW談OO.. 是不是搞錯重點了
推 azukikao: 整個linux kernel都很OO 可以去看看如何用C寫OO的資訊
→ azukikao: 搭配kernel讀 認真看保證會有收穫
可以請問一下為何上面有人不推OO?好像存在著正反兩端的意見捏
※ 編輯: zzss2003 (118.163.216.18), 01/22/2019 17:37:46
→ ggBird: 看你是信 linux kernel 還是信不認識的鄉民
謝謝GG鳥大大，嘻嘻
※ 編輯: zzss2003 (118.163.216.18), 01/22/2019 18:13:10
→ i386: 你的問題1，建議你找一段自己寫的程式然後把他畫成流程圖，
→ i386: 看看這圖是不是很醜，是的話，請重畫出好看的圖，然後照圖
→ i386: 的步驟去寫code
→ i386: 問題1其實跟懂不懂物件導向關係不大
推 PBDS: 其實韌體就只要做到，訊號進的來，資料出的去，工程師發大財
→ PBDS: ！
推 join183club: 可以說說你寫過那些driver嗎?
推 since0258741: 你不是夜市學店那一位嗎？電池沒做了
→ since0258741: ？
推 ohohohya: 來寫BIOS啊
→ ohohohya: 你講的這些來寫UEFI bios都有
推 badyy: 拿現成BIOS/bootloader精進coding能力喔......XD ! 怎麼跟
→ badyy: 高級長官說的都不太一樣XD
推 future314: UEFI程式比較簡單環境也較單純 作為學C的OO其實還可以
→ future314: 但是應用面很窄 還是直接學kernel或RTOS比較快
→ badyy: 真的環境簡單XD OS BSOD,chip 莫名reset都算你的XD
推 chuegou: 1. 21世紀C語言 / OOP in C可以拿來翻
→ chuegou: 2. 資料流和領域知識可以輔助你更快進入狀況 就認真問吧
推 chuegou: 4. 目的是要做啥？好維護？那還是選比較多人用的比較好
推 aoqq12: 其實不是OO不好  是每個人寫的OO都不一樣
→ aoqq12: 寫久了就亂七八糟了
→ aoqq12: 在C++上已經有IDE幫你統一寫法  在C上各自發揮
→ aoqq12: 會用OO來寫code很好，但是如果四不像的OO簡直災難\
→ aoqq12: Kernel code是一群高手的集散地，也一群人一直在修改
→ aoqq12: 公司的寫code 光是人力 時程問題就會讓你的code產生災難
推 GTX9080: 推訊號進的來，資料出的去XD
推 askacis: Linux kernel的code漂亮又洗煉，OO精神無所不在，不是mcu
→ askacis: 等級的code可以比的
→ brianhsu: Linux kernel 必看吧！
推 DSB520: Linux kernel跟OO差的遠了 不是模組化就是OO勒
推 usan: 不用急，多做幾件案子，從經驗中學習
推 jeff12302000: FW 有晶片容量限制......有時候你還得拋棄高階語言
推 jeff12302000: 然後RTOS跟State-machine 根本兩碼子事情...你那句
→ jeff12302000: 什麼意思我完全看不懂