※ 引述《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. --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.135.18.57 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1660998408.A.76F.html ※ 編輯: tinlans (220.135.18.57 臺灣), 08/20/2022 20:42:29