※ 引述《Ferrara (紅燒冰淇淋)》之銘言： : 本ID在台北一家陸商待過一個月 : 發現對岸SW RD的整code習慣是這樣 : 覺得自己寫好了，就commit了 : commit之前不做驗證，不初步抓一下bug : 連local build pass都沒有 : 負責管respitory 的人得一條條幫他們檢查 : 最近被一家台陸合資的公司找去面試 : 主管說他在管理gerrit的時候很難整合daily build : 因為對岸的工程師丟上來的東西常常build不過 : 請問各位鄉民 : 你們共事過的對岸工程師也會這樣嗎 分享一下現在中國公司工作的狀況好了， 程式碼 build 都沒過，是絕對不能回家的，你會害很多人被扣錢。 首先程式碼 commit到分支前，都要設定好jenkins 使用 git push 程式碼到 repository 的分支時， 會觸發CICD流程，大致會執行以下流程: 編譯 build --> 弱點掃描 --> 程式碼取名規則檢查 --> UT Test 除了程式沒有語法上的bug 可以build 如果程式碼的變數，函數名稱不符合規範， 或程式碼有常見弱點，或缺陷defect CICD是不會通過的。 UT Test 除了測功能外，還要滿足測試程式碼的覆蓋率 Coverage。 如果 UT 的 Test Case 亂寫，或是Test Case 沒有覆蓋到75%的程式碼，CICD也不會過。 功能正常還是不夠的， 現在幾千萬人使用，7x24 的系統，非常追求程式碼的穩定，效率，可維護，透明。 我們公司一出現停機的Bug，一堆人都要扣幾千塊人民幣的。 我們也在意機器查不到的業務邏輯 Bug。 還要在意可維護性，也要避免有寫作弊程式碼，不可維護的黑箱，神秘的隱藏程式碼。 所以程式碼能跑，還不夠，要靠人去提高程式碼的品質。 接下來就是透過 gerrit，去找人 review程式碼。 review的人，有不同的權限，至少要有權限高的人+2 才能將程式碼merge到分支。 這時候，問題就來了，那麼review的人偷懶不就好了? 大家省事。 當初我也是這樣想的。 你的同事或資深工程師Review完的Comment， 每周會有更資深的工程師或部長，再檢查這些人的review是否合理。 程式碼出了事情，停機了，這些資深工程師都是要扣薪水的。幾千幾千人民幣的扣。 所以除非你是老闆兒子，不然你討好同層，或討好主管根本沒用。 另外，一次交大量的程式碼，減少review次數，也是不行的。 超過300行程式碼的commit 都會要有資深工程師或主管審核，才能夠merge程式碼， 而且每日自動檢查會通報一次性review超過300行程式碼的行為。 沒有Bug，CICD過了，review過了，程式碼merge到分支，總沒事了吧。 我剛來公司時也是這樣天真的。 結果合併到分支的程式碼，每天定期都會自動跑CICD， 而且UT會因為網路不穩連接時間太長失敗。 網路不穩，怪軟體工程師囉? 對，就是那麼坑。 晚上12點CICD沒過，不管是不是程式碼本身的問題， 你和你的主管都要扣本月績效分數，影響本月薪水。 所以沒人敢讓每日定期檢查的CICD不過。 所以程式碼的Test Case又要很聰明的，知道何時使用mock測試， 避免各種網路連線不穩定的UT測試失敗。 哇靠，那麼麻煩，我乾脆不寫程式碼或少寫好了，寫越多事情越多。 不行喔，每周/每月，都會統計程式碼行數， 然後大家比較一番，然後落後的人給點壓力。 以上只是每日的開發工作， 每周還有Coverity的靜態程式碼掃描，不過就通報。 軟體發新版本時，測試工程師從分支拉取程式碼， Coverity的靜態程式碼掃描不過，也進不了發版本的測試階段。 當然Coverity的掃瞄常常誤報，即使誤報也要走流程，然後安全專家同意去取消。 其他懶得說了，反正一堆為了提高軟體品質的規定，走火入魔的規定比較常見。 有空再交流。 -------------- 當然不是每家中國軟體公司都這樣搞人的。 但是，真的沒聽過 build 不過，還可以正常混到薪水的。 有的這種公司話，請站內信推薦，真的。一定一堆人搶著去爽。 ※ 編輯: DrTech (116.77.73.243 中國), 11/06/2020 23:08:12 ※ 編輯: DrTech (116.77.73.243 中國), 11/06/2020 23:36:57