: 因為想脫離design house的生活
: 一直有在刷題+補充Cpp, oop 相關知識
: 之前有幸找到一份junior寫Cpp的工作
: 想了解對各位來說,有沒有一個對於qualified cpp programmer的具體標準
: 我的理解:
: Junior:
: 1. 熟練STL, 能解決被交付的工作
STL 之外 boost (
https://www.boost.org/) 也要會用一點,
有餘裕的話這兩個也稍微看一下:
https://abseil.io/有餘裕的話這兩個也稍微看一下:
如果確定公司偏好用哪一套的話可以指向性學習。
不需要盲目去學整套,至少要有從裡面選東西來解決問題的能力即可。
: 3. 熟練使用template (之類的
你能把 STL 用得熟其實就包含這兩者了。
所謂 template 的使用其實有區分,一個是像使用 STL 那樣人家寫好的來用,
一個是用 template 設計函式庫,後者不是一定需要,實際上常用不太到。
: 4. oop所謂 template 的使用其實有區分,一個是像使用 STL 那樣人家寫好的來用,
一個是用 template 設計函式庫,後者不是一定需要,實際上常用不太到。
這對於寫出容易交接、容易合作、容易讓人看得懂的程式碼有幫助。
也有公司完全不用 OOP 在寫 C++,這很看你進的公司是幹嘛的。
總之先學好不是壞事,確定上面有 seinor 帶你的話可以進去邊被罵邊學。
這個臉皮可能需要厚一點乖乖被罵,每個人都有這時期,有人帶比自己亂學得好。
另外我覺得最重要的還有幾個:
5. 編譯、連結錯誤的訊息要看得懂,連這個都卡住還要問人的話很容易變累贅
6. 懂得使用除錯工具,以 Linux 環境來說就 gdb、valgrind、address sanitizer 等。
包括程式不小心掉進無窮迴圈,你要知道怎麼讓除錯工具攔截下來看到底在幹嘛。
7. 特定作業系統的開發工具組,我知道要寫 C++ 的有不少是 Linux 環境開發,
如果連基礎 Linux 指令都不會下,g++ 和 clang++ 指令都還要問人的話就有點慘
8. 寫出讓別人容易看懂的程式,不要炫技,寫每一行之前都先考慮別人看不看得懂
9. 會用 git 之類的版本控制軟體
: Senior:也有公司完全不用 OOP 在寫 C++,這很看你進的公司是幹嘛的。
總之先學好不是壞事,確定上面有 seinor 帶你的話可以進去邊被罵邊學。
這個臉皮可能需要厚一點乖乖被罵,每個人都有這時期,有人帶比自己亂學得好。
另外我覺得最重要的還有幾個:
5. 編譯、連結錯誤的訊息要看得懂,連這個都卡住還要問人的話很容易變累贅
6. 懂得使用除錯工具,以 Linux 環境來說就 gdb、valgrind、address sanitizer 等。
包括程式不小心掉進無窮迴圈,你要知道怎麼讓除錯工具攔截下來看到底在幹嘛。
7. 特定作業系統的開發工具組,我知道要寫 C++ 的有不少是 Linux 環境開發,
如果連基礎 Linux 指令都不會下,g++ 和 clang++ 指令都還要問人的話就有點慘
8. 寫出讓別人容易看懂的程式,不要炫技,寫每一行之前都先考慮別人看不看得懂
9. 會用 git 之類的版本控制軟體
: 1. 能設計軟體架構
如果上面沒有系統分析師或系統設計師也沒架構師在,這兩個也不能說不對。
只是這跟 C++ 比較沒有關係,它比較偏跨語言的泛用知識。
把 C++ 學得超級好也未必能修得這類技能,這技能樹的起點和 C++ 算是平行。
: 2. 活用design pattern只是這跟 C++ 比較沒有關係,它比較偏跨語言的泛用知識。
把 C++ 學得超級好也未必能修得這類技能,這技能樹的起點和 C++ 算是平行。
先假設你指的是物件導向的 design patterns,
如果你的想法是 C++ 先學好,然後就直接跑去學 design patterns 並靈活運用,
那麼我要以一個寫 25 年 OOP 程式的過來人告訴你:此路不通。
還好不像十年前一樣,現在講這個已經有網路文章能參考了,可以讀一下這兩篇:
先學物件導向還是先學設計模式?
https://teddy-chen-tw.blogspot.com/2014/03/blog-post_26.html如果你的想法是 C++ 先學好,然後就直接跑去學 design patterns 並靈活運用,
那麼我要以一個寫 25 年 OOP 程式的過來人告訴你:此路不通。
還好不像十年前一樣,現在講這個已經有網路文章能參考了,可以讀一下這兩篇:
先學物件導向還是先學設計模式?
Top-down和Bottom-up設計方法
更精確來說,物件導向整個領域除了 OOP 之外還有 OOA 跟 OOD。
傳統軟體開發流程一定會看到的就是需求、分析、設計、實作幾個階段,
design patterns 是 OOD 階段的函式庫,你光會套用函式庫和你會設計是兩碼子事。
如果你壓根不知道軟體開發是怎麼從需求走到設計,
design patterns 直接啃下去然後拿來用,幾乎可以說 100% 會出大事。
就像有人 20 年前用 Borland C++ Builder 寫得一手好 GUI 軟體,
VCL 元件庫沒有一個他不知道怎麼用的,
但是他 C++ 底子可能爛到不堪入目,
連自己實際上在寫什麼東西都不知道。
程式不但很難讀懂,別人接手他的程式碼每個都會想砍掉重練。
話題有點扯遠了,比起上面的兩個能力,我會比較注重這些:
1. 程式碼重構能力 (refactoring),比起預先設計,我更喜歡先照直覺寫再重構
2. 懂測試驅動開發 (test-driven development),盡量以測試程式代替死版的技術文件。
這個和程式碼重構通常是搭配在一起的東西,能確保你每次重構都沒改壞。
測試框架如 Boost.Test 或 Google Test 等等的能熟悉一兩種最好。
3. 有辦法 review junior 的程式碼並給予正確指導,人帶不好你一個人寫還比較快。
公司有引入 Phabricator 或 Gerrit 的話,要熟悉怎麼善用它。
4. 完備的 OOP 知識,有少許 OOA 和 OOD 概念,寫出的程式可以應對需求快速變化,
不要遇到需求改來改去就只會想著揍主管、揍客戶或是辭職把鍋甩給別人
5. 完備的多執行緒和非同步程式開發能力,並知道如何除錯
6. 廣泛涉獵各種框架和函式庫,如 Qt、C++ REST SDK、redis-cpp 等等,
當然允許混用不同程式語言開發的話,可以在非效能關鍵部分結合別的語言,
然後搭配 SWIG、gRPC 等工具把不同語言開發出來的程式連接起來
7. 能快速評估第三方函式庫是否適用於自己的專案,有辦法 trace、修正問題並擴充
8. 隨時跟上 C++ 最新標準,最近十幾年 C++ 標準也開始飆車了,不要輕易被甩下車
9. git flow、github flow、gitlab flow 這些也要熟悉到一個程度,能指導 junior
在 4. 我並不強調 design patterns,有興趣碰自然是更好,但相關基礎先打穩再說。
如果你團隊裡 senior 之上就沒有人統籌規劃架構,那可以再進階以圖自立自強。
這顆技能樹完全長在跟 C++ 不同地方,不是你 C++ 學到極致就能跨過去。
你要點亮它的話可能要先知道怎麼從需求走到 OOA,然後再從 OOA 走到 OOD。
這部分有個概觀就好了,後續是搭配現代的各種敏捷開發法一起使用。
上面給的連結也會告訴你就是需要混合 bottom-up 和 top-down 東戳一點西戳一點,
硬用線性學習法你只會覺得自己像在讀國文課本一樣,很難靠自己吸收到真髓。
所以與其說它是技能樹,實際上是可以跳著點的,沒有先練好什麼才能練什麼這種事。
C++ 也是同理,整個學習方式幾乎都是先零散學習最後才連起來。
這語言複雜歸複雜,實際上不用全學好還是能拿來工作,等全學完再上你都變老人了。
: 故認真發問
: 歡迎各種補充
--
Ling-hua Tseng
Architect
Research & Development Department
Stranity Technology Co., Ltd.
--