Re: [討論] 怎樣算是一個合格的junior cpp programme

※ 引述《musashi023 (太陽魚)》之銘言：
: 諸位資工大神好，我本身是EE背景的
: 因為想脫離design house的生活
: 一直有在刷題+補充Cpp, oop 相關知識
: 之前有幸找到一份junior寫Cpp的工作
: 想了解對各位來說，有沒有一個對於qualified cpp programmer的具體標準
: 我的理解：
: Junior:
: 1. 熟練STL, 能解決被交付的工作
STL 之外 boost (https://www.boost.org/) 也要會用一點，
有餘裕的話這兩個也稍微看一下：
https://abseil.io/
https://github.com/facebook/folly

如果確定公司偏好用哪一套的話可以指向性學習。
不需要盲目去學整套，至少要有從裡面選東西來解決問題的能力即可。

: 2. 熟練應用資料結構
: 3. 熟練使用template （之類的
你能把 STL 用得熟其實就包含這兩者了。
所謂 template 的使用其實有區分，一個是像使用 STL 那樣人家寫好的來用，
一個是用 template 設計函式庫，後者不是一定需要，實際上常用不太到。

: 4. oop
這對於寫出容易交接、容易合作、容易讓人看得懂的程式碼有幫助。
也有公司完全不用 OOP 在寫 C++，這很看你進的公司是幹嘛的。
總之先學好不是壞事，確定上面有 seinor 帶你的話可以進去邊被罵邊學。
這個臉皮可能需要厚一點乖乖被罵，每個人都有這時期，有人帶比自己亂學得好。

另外我覺得最重要的還有幾個：
5. 編譯、連結錯誤的訊息要看得懂，連這個都卡住還要問人的話很容易變累贅
6. 懂得使用除錯工具，以 Linux 環境來說就 gdb、valgrind、address sanitizer 等。 包括程式不小心掉進無窮迴圈，你要知道怎麼讓除錯工具攔截下來看到底在幹嘛。
7. 特定作業系統的開發工具組，我知道要寫 C++ 的有不少是 Linux 環境開發，
如果連基礎 Linux 指令都不會下，g++ 和 clang++ 指令都還要問人的話就有點慘
8. 寫出讓別人容易看懂的程式，不要炫技，寫每一行之前都先考慮別人看不看得懂
9. 會用 git 之類的版本控制軟體

: Senior:
: 1. 能設計軟體架構
如果上面沒有系統分析師或系統設計師也沒架構師在，這兩個也不能說不對。
只是這跟 C++ 比較沒有關係，它比較偏跨語言的泛用知識。
把 C++ 學得超級好也未必能修得這類技能，這技能樹的起點和 C++ 算是平行。

: 2. 活用design pattern
先假設你指的是物件導向的 design patterns，
如果你的想法是 C++ 先學好，然後就直接跑去學 design patterns 並靈活運用，
那麼我要以一個寫 25 年 OOP 程式的過來人告訴你：此路不通。

還好不像十年前一樣，現在講這個已經有網路文章能參考了，可以讀一下這兩篇：
先學物件導向還是先學設計模式？
http://teddy-chen-tw.blogspot.com/2014/03/blog-post_26.html

Top-down和Bottom-up設計方法
http://teddy-chen-tw.blogspot.com/2014/03/top-downbottom-up.html

更精確來說，物件導向整個領域除了 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.

--