對岸的軟體工程師 - 工程師

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