Re: [討論] 對岸的軟體工程師
※ 引述《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
親!信你了!
人力成本超高...，方便問sprint和release週期嗎？
發版的周期是，每個月發兩個release版本。長假前後凍結。
也太硬...突然覺得現在過好爽
人力成本其實不高，風氣就是晚上8點算早下班。
加班根本不給薪水，是福報阿。真心羨慕原文那種隨意公司。
好猛，除了很硬，扣薪也太可怕
親 你好猛
還好我一行都拆好幾行寫0..0
扎心了 老鐵
這篇可信度高
規模大了就變法治，有些地方就踩很硬
沒想到寫程式也跟學音樂ㄧ樣，練習不夠，隨便亂寫，都有
人知道
我決定開始點炸雞排的技能樹了...
原po大神
好恐怖
這麼肝是給多少啊...
我以為只有 google 會注意軟體品質
哥 您年薪？
這跟年薪與能力無關吧。剛畢業的大學生也是這樣管理。
一個code review這麼多遍人力成本當然高。有沒有加班費是
另一件事情。
只能說有經驗的公司，早就把人性看得很透了，所以訂一堆
規則防止人偷懶或失誤。
沒想到大陸也有公司走這套了,直接扣幾千人民幣真的會怕XD
之前請上面code review還要一直寄信跪求QQ
原po這間都是local pay再加一點點 XDDD
所以一個月就閃了
一個月兩次 release 有點少,通常我們都一個禮拜四次
盡量發布小的 commit, 有問題都可以很快 trace
原 po 公司可能是金融相關的？才會用這麼嚴謹的方式上版？
突然想到 每個月生這麼多程式碼 改這麼多碼 修這麼多bug
H
最後這系統到底會變成什麼 這麼多人才生出來的東西 肯定
很強很潮吧 若不是這樣就很無奈了...釘不完的釘子阿....
一個禮拜四次release? 這好像有點屌.....
我現在是做多媒體串流平台的後台，現在用戶多的軟體出問題
扣薪水也太硬
一定會被對手炒作，市場蠻競爭的，要對Bug充滿敬畏之心。
幹這太可怕了吧…
反正台灣科技仔都覺得阿共都很弱 ㄎㄎ
好嚴格... 只能仰望了
看台灣那些兩光的網銀系統就知道台灣的IT太混!
大陸現在很流行扣薪水的感覺
不會管理寫程式才需要這樣搞
除了扣錢之外，真像mtk modem team QQ
華人就是乖乖奴阿，很多人喜歡這種狼性，好棒喔
只會扣錢....
@havochuman 以偏概全不就好棒棒? 活在自己世界?
不會管理寫程式才需要這樣搞+1
然後繼續酸亞麻血汗工廠..雖然沒錯xd
敬畏之心…怎麼很像習領導的話
美國亞麻的血汗是跟養老Google比較出來的, 跟中國/亞洲
公司比工時應該一半都不到
我們歐洲公司也是這樣差不多，不會扣錢。不是互聯網公司
壓力比較小
推文一堆沒見過市面？？ 這正常流程而已吧？
google你想趕快promote也可以超累阿...
而且美國公司也沒再給加班費的
看程式碼行數XD，一推爛code寫的都超級長的
能好奇做到那麼硬年薪大概多少嗎，不被扣的情況
其實外商都這麼做...
還有merge也是有準則的 請看git的文件
CICD後來越做越瘋 連format跟註解都會檢查才給你過
統計行數...意義不是很大吧，有impact的可能只有一行
統計行數有意義啦。有用clang format限定格式你就不能隨
便換行，formatter會自動換行，然後空行和註解不會算行
數
而且reviewer也不是白癡，你想偷行數大家都看得出來會叫
你改
還是有差 用?:;和if else就差四行了
扣薪比較可怕 其它還好
通常數十人上百人在寫的程式都要這樣管理
其實在這種環境你才會成長，兩種公司我都待過，現在覺得
待那種亂commit的小公司根本浪費寶貴的青春。
很多程式是要交付給客戶的 所以書寫風格也要統一
人是會成長的，一開始壓力會大一點，但等你程度跟上之後
就會變輕鬆一些
我們公司的程式碼規範，是要刪除空白行的喔，投機故意增加
數，revier 時會被要求修改。
我也覺得做這些意義不大，浪費時間，但是其實習慣了以後，
搞這些流程時間不會增加太多，但是程式碼會變得很專業好維
護。
現在我自己反而比較習慣看，緊湊乾淨，的程式碼風格。
全部都很正常，除了扣薪
你這樣會讓蛙蛙崩潰
另外，版友說的很對，不會管理才這樣搞。中國風格就是，懶
得管理就禁止你做，不知道怎麼改善就用罰錢。
這篇很值得參考！
優文
中國公司就強的很猛 爛的糞爆 後者比前者多
人夠多就應該朝這個方向弄
一堆沒見過世面的,人越多越不需要這樣搞,會這樣搞代表管
百人專案幾十萬行的code一定要用CICD人工管理太不靠譜
理程度低落,程式能力差,人一多就handle不了
幾百人的專案代表每個人的loading越輕,搞成每個人loading
變重,程度奇差無比
看不出這樣有搞問題的還一直推崇的,程度也是相當低落
所以樓上意思是要去待亂commit的小公司？
覺得被搞扣薪水才是公司主要獲利來源吧？
人越多做的東西也可能越多
CICD不一定是最佳解，但是要找到不用CICD同時也能夠維護
程式品質的公司實在太稀有，比日本製壓縮機還稀少。
好猛，但是真的嚴謹適合超大專案的維護
規模大的公司只要是跟Coding有關的多多少少都有CICD機
制
屌欸，不過也正常中國程式都給幾千萬人用，爛code的影
響太巨大
挖靠....拿程式碼commit行數當kpi也太鳥了吧...
以後統一了台咖就是oncall debugger啦對大陸主管負責
用扣薪真的很恐怖。既然如此高壓 那給薪肯定高吧？
那請問幫人review有加錢嗎 不然出事扣錢沒出事也沒加錢
誰要幫別人review
這種不會變成每天review code就飽了？
Dr tech必推
errr 花很多時間看 PR 在大型軟體超常見好嗎...
該改的是背鍋文化吧
外商都是發 PR 給 approval 滿標者才 merge 咩
MR 發出去自動跑 jenkins pipline 或 gitlab pipline
做基本檢察和測試
我們公司每半年才 release 一個主版本，release 前除了基
本 CICD 要跑得過以外，還寫了規模不小的整合測試框架
跑完框架也都是 24h 以上的時間，release 前還要由不同人
去手動測，再加上還要跑 perf test 和 long run test 才可
release.
有bug扣薪合理，但是年薪低應該找不到員工吧
給太少 臺灣人還會做飛機去中國打工嗎?
是給你多少錢 一直扣好幾千還幹的下去喔
一看就知道是大公司
很多外商也都這樣了吧，但還是有辦法產出一堆垃圾
遇過某中國手機致敬王者公司bsp rd build img後boot會死
機 問是不是我們改了什麼 我滿頭問號 從沒release新bin
反問他們有改什麼 兩個rd一個說checkout有問題 所以退回
前一版ok 另一說直接用最新checkout然後這樣了 然後他們
兩吵了起來...就算build也是需要整體性驗證...更何況不能
build還上code...
看行數比較我笑了
目前我明明是寫韌體的，卻還要去檢查ui的bug 坑
這真的是有經驗的才知道XD
聽起來是真碼農
這一定是給高薪的大公司了
牛
台灣二線公司, 花錢買coverity授權都...
小公司就更別談了
如果這樣搞法,公司還不願意花錢請頂級人才
一堆測試問題就把錢都給扣光光了
用過國際第一流大廠(非台商)的SDK, 問題都一卡車了...
其實扣薪水都不是什麼大錢，有些公司就是 fail build 請
全公司飲料咩，群暉以前也有這樣做
一般 "有制度" 的 "大" 公司流程都是這樣
還有在比行數??
聽完我想去賣雞排了 有夠硬
gerrit code review、Jenkins、coverity都算有意義，可
以增加軟體品質。不過算行數真的很好笑，依LinkedList
為例，Datapath寫的漂亮的和爛的，總行數可能差到三倍以
上。
推
看起來就是正經在做事情的公司，而且有一定規模
行數 只是為了比較 讓你感到羞恥而已
這點不是很人性就是了 會因爲這點而做不下去
這麼多毛的公司我pass
扣除行數要求，這些要求都還好吧？
好想去開眼界啊...
比行數真的不知道能幹嘛..程式重點不是演算法嗎？好的演
算法比寫一堆垃圾code去拼出功能好多了
這看起來很正常吧...
嗯,的確很正常,很多大公司軟體程度就是這麼低落,這樣的
CICD若對提高品質有效的話,馬上就不需要commit程式碼了,
還一直要求commit程式碼,邏輯錯亂的一堆
跟產線的良率當KPI 87%像 有的血汗公司產線良率還會採連坐
法 科科
除了扣錢 其它都蠻合理的
這種公司能永續發展才奇怪 動不動就罰錢
小公司的爛才是突破天際
行數當kpi到底是什麼爛管理腦= =
除了行數kpi還有扣錢以外，以軟體開發來說剛剛好而已
推
扣錢XD
UT是啥 unittest？？？這也要簡稱？
以軟體開發來說這就是大公司做法啊 除了扣錢
仔細看敘述，行數不是KPI
比行數，真的笑了
除了扣薪其他和M相似
除了扣薪和算行數 其他算常見的作法
29
Re: [心得] 好的註解是解釋為何需要這段 code上週在重構某段程式碼時，其中一位同事在 code review 中建議把某個註解刪掉，另一 個同事看到這個評論時，在下面留了言說他認為不應該刪掉，於是我們就拉了一個小討論 ，聊在程式碼中寫註解這件事。 因為這個經驗，我回去重翻史丹佛電腦科學教授 John Ousterhout 寫的《A Philosophy of Software Design》一書，並整理了筆記。該教授的觀點是認為程式碼寫註解有很多好![Re: [心得] 好的註解是解釋為何需要這段 code](https://www.explainthis.io/static/images/twitter-card.png "Re: [心得] 好的註解是解釋為何需要這段 code")
24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題，來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼，重寫舊的程式碼成自己爽的樣子，不一定是重構。 3. 重構是一種相對安全的工具型開發方法論， 但仍然有不少風險跟誘惑。13
Re: [請益] 發現同事反組譯自己程式碼怎辦恩~~~就像你原文所講的，你的同事都在用反組譯了，也就代表了沒有拿到程式碼 那究竟有甚麼問題，我其實搞不太懂 之前在面板廠工作的時候，我都很歡迎我的同事大量使用我的程式碼， 每周部門會議時，我就公開說我做了XXX000，歡迎大家來使用 因為都在同部門，沒有必要重新造輪子X
[情報] 1800 神魔特別報告 遊戲測試部情報來源網址： 懶人包 正在重構底層程式碼 大家好！我是『神魔改革行動部』中的測試部負責人蜜瓜包，感謝大家再次觀看『1800 神魔特別報告』。今天由我回應大家關注的問題。 ==================================4
Re: [討論] 重構跟kpi的考量我覺得有個盲點就是 重複程式碼的邏輯 我的經驗是在需求還沒穩定前 一樣的程式碼複製到不同地方才是最佳解 你根本不知道什麼時候 某個地方要用的邏輯不同 一但要改寫的邏輯不通 你就會被共用的程式碼卡住7
Re: [閒聊] 寫程式真的這麼邪門嗎？呃 講這個其實蠻尷尬的 因為綠乖乖是最省錢的解（？）XD 一般來說要提升程式碼品質 一些軟體工程的東西要確實執行6
Re: [問卦] 寫程式的基本功是什麼?寫程式的基本功是寫測試 再好的程式碼如果沒有寫測試保護，就有機會在上線才知道程式碼被改壞掉。 平常有在寫測試的人，寫的程式碼也好讀很多，因為把程式碼寫太難會很難寫測試 --4
Re: [討論] 用AI寫code產生的疑問先講結論，軟體工程師做的事情以及定義從 1946 年 ENIAC 開始就不斷地在改變。 所以接下來改變的還是會是工程師的定義，也許依照人力資源規劃還是會有各種 工程師職階，但是做的事情和現在應該不會一樣。 順帶一提，目前的 GPT 其實還沒辦法完成很多開發工作，所以也許一兩年大家都摸清![Re: [討論] 用AI寫code產生的疑問](https://i.imgur.com/abE2zRMb.jpg "Re: [討論] 用AI寫code產生的疑問")
Re: [問卦] github之類的程式碼代管為啥不直接用網頁你需要的是Git就好了 Git原本是整合多個工程師一起寫程式時 快速Debug和研發程式的工具軟體(版本 主幹 分支) 只是侷限於本端 GitHub的功能雖然也有上述的內容 不過他是遠端數據庫
![Re: [新聞] 不缺電但不夠用！經部喊話AI大廠：請](https://i.imgur.com/U5J6lemb.jpeg "Re: [新聞] 不缺電但不夠用！經部喊話AI大廠：請")