[討論] 產量高品質差的工程師

看板Soft_Job作者 (LKK)時間1月前 (2024/08/01 11:15), 1月前編輯推噓63(71推 8噓 151→)
留言230則, 98人參與, 1月前最新討論串1/8 (看更多)
大家有沒有遇過這樣工程師… 我們公司最近在開發新的專案，找了一位新來的工程師幫忙一起做。這個人Coding速度真 的很快，交給他的功能很快就能做出來。每個sprint下來，他也一直不停的接新ticket和 開發新東西。 最近這個新專案終於要上線了，結果QA卻測出了一大堆bug！！由於數量真的太多了，但 又為了承諾客戶如期上線，所以只好把我和其他2個工程師也叫來，一起昴下去幫忙解bug … 結果不去看還好，一下去看他裡面的code，真的是非常可怕…又臭又長像流水帳一樣，結 構也是亂七八糟，很多邏輯明顯沒有想過或設計過硬幹去寫出來，沒有任何彈性和維護性 ，大家花了非常多時間再改他的程式，真的改的非常辛苦... （對…我們為了趕這個專案，完全skip code review、skip unit tests 等等。二來 這 新專案相對獨立，不影響現有系統。所以他commit 什麼 就merge什麼，鬧得今天這下場 。我們的例子，正好回應前幾篇某些人質疑為何要code review......） 最後產品雖然如期上線，但這下好了，老闆和PM現在超喜歡這個工程師，後面很多v2 要 衍生的新功能，都要叫這位工程師來主導開發… 我們幾個幫忙「收爛攤子」的人，聽到真的有種不好的預感…一來害怕又有更多有問題的 程式被他寫出來，後面又要花更多時間來修改；二來有種功勞你在接，爛攤子我們在收的 感覺… 我們原本找主管說這些問題，但目前公司大老闆想正積極開發這項產品，他們只希望快點 見到結果，似乎也不太在乎原有的開發流程了，只想先快點把東西生出來，給客戶demo… 各位如果面對這種情況，和這樣的工程師該怎麼辦？公司想快速看到成品，找了一個產出 快的人，雖然短期快速看得到成果，但卻後患無窮… -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.145.105.198 (澳大利亞) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1722482140.A.F7E.html
推
08/01 11:18, 1月前 , 1F
離職
08/01 11:18, 1F
推
08/01 11:24, 1月前 , 2F
屎擦太乾淨，以後負責專門擦 笑了
08/01 11:24, 2F
形容的太貼切了！所以我們現在超怕他繼續接下去做後續的功能..
推
08/01 11:30, 1月前 , 3F
有bug當然叫commit的人處理吧，你去擦屎幹嘛
08/01 11:30, 3F
→
08/01 11:31, 1月前 , 4F
叫他一人負責就好 其他人去忙其他專案
08/01 11:31, 4F
沒辦法…我們不是老闆…這案子是公司目前最重要的任務，主管要我們其他人補上去修， 也很難退掉吧.. ※ 編輯: yestheway (1.145.105.198 澳大利亞), 08/01/2024 11:42:57
→
08/01 11:47, 1月前 , 5F
不是測過才算產量嗎? 不會動的也能算產量?
08/01 11:47, 5F
很好的問題！因為這些新功能都沒有unit test, integration test 等等，完全依賴QA手 動測試，在90%的情況程式都能動，但像是換個環境 改個context後，某些情況就掛了…
→
08/01 11:47, 1月前 , 6F
驅動生產 反正你們會如期修好
08/01 11:47, 6F
→
08/01 11:48, 1月前 , 7F
怎麼會很難推，除非你真的很想待下去那你活該
08/01 11:48, 7F
其它同事我不知道，但我個人有簽證關係，沒辦法這麼瀟灑走掉…當然 相信解決問題 還 是有除了離職以外 更好的方式吧
→
08/01 11:49, 1月前 , 8F
你們自己沒有驗收條件就算結案很奇怪餒
08/01 11:49, 8F
推
08/01 11:52, 1月前 , 9F
想辦法把他捧起來 之後好處理
08/01 11:52, 9F
推
08/01 11:55, 1月前 , 10F
之前不是有啟智說不用code review review是要看什麼
08/01 11:55, 10F
→
08/01 11:55, 1月前 , 11F
怎麼現在那種人又消失了
08/01 11:55, 11F
→
08/01 11:56, 1月前 , 12F
影響正常運作的bug還能算量？
08/01 11:56, 12F
大部份情況都是能運做的，但某些例外狀況 原本可能沒被測出來吧......
→
08/01 11:58, 1月前 , 13F
直接講不聽就投到他直屬主管那邊啊，他主管不喬是他的
08/01 11:58, 13F
→
08/01 11:58, 1月前 , 14F
事情，出問題就把他們兩個推出去扛刀。
08/01 11:58, 14F
※ 編輯: yestheway (1.145.105.198 澳大利亞), 08/01/2024 12:07:33
推
08/01 12:01, 1月前 , 15F
就不要修啊 大不了一起爛
08/01 12:01, 15F
推
08/01 12:05, 1月前 , 16F
接案出身？
08/01 12:05, 16F
→
08/01 12:06, 1月前 , 17F
感覺你團隊問題也蠻大的欸..
08/01 12:06, 17F
我也覺得他是做接案出身的…並不是說做接案的人不好，但真的看過太多這類接案工程師 ，那種虛應一應故事 交差了事的做事方式… 但我們是在做SaaS自己的產品，原本的開發節奏雖然不算快，但要求很嚴謹 該做的都要 做到位review才會過。但現在為了敢這個新專案，完全亂了陣腳，搞出一堆「技術債」 到頭來這些不健康的程式，也是必有人要來修…. ※ 編輯: yestheway (1.145.105.198 澳大利亞), 08/01/2024 12:34:11
→
08/01 12:22, 1月前 , 18F
沒有維運過自己開發的工程師，很大機率是垃圾量產機
08/01 12:22, 18F
推
08/01 12:35, 1月前 , 19F
我好奇他寫好的時候不用先跑一下看看有無問題嗎？
08/01 12:35, 19F
→
08/01 12:42, 1月前 , 20F
開規格、測案開嚴一點，然後叫他自己全測過
08/01 12:42, 20F
推
08/01 12:51, 1月前 , 21F
好像我們公司
08/01 12:51, 21F
推
08/01 13:14, 1月前 , 22F
看起來是驗收機制有問題吧 而且主管不會覺得一個人開發
08/01 13:14, 22F
→
08/01 13:14, 1月前 , 23F
要三個人維護哪裡怪怪的嗎
08/01 13:14, 23F
推
08/01 13:15, 1月前 , 24F
離職阿，那mo簡單
08/01 13:15, 24F
推
08/01 13:20, 1月前 , 25F
出個包讓老闆痛
08/01 13:20, 25F
→
08/01 13:38, 1月前 , 26F
需求定義不明確吧，怎麼會有因環境程式出錯
08/01 13:38, 26F
推
08/01 13:43, 1月前 , 27F
如果要你們幫忙，那功能設計初期，你們應該可以加入吧
08/01 13:43, 27F
→
08/01 13:43, 1月前 , 28F
！就要求流程，把merge的權力拿走，既然老闆要你們幫忙
08/01 13:43, 28F
→
08/01 13:43, 1月前 , 29F
，我是不認為你們無法要求啦！這樣也可以讓這個工程師
08/01 13:43, 29F
→
08/01 13:43, 1月前 , 30F
知道你們的要求，不急著他可以一步到位的改寫成符合你
08/01 13:43, 30F
→
08/01 13:43, 1月前 , 31F
們的想像，但至少你們的工作也可以隨著紀錄一起被看到
08/01 13:43, 31F
推
08/01 13:47, 1月前 , 32F
樓上把老闆想得太美好了，老闆都覺得這樣的人超讚
08/01 13:47, 32F
還有 158 則推文
還有 6 段內文
推
08/03 18:14, 1月前 , 191F
你們問題在開發流程，你不即時Review誰剛來會知道
08/03 18:14, 191F
→
08/03 18:14, 1月前 , 192F
公司的coding style，除非你們有linting tool在管
08/03 18:14, 192F
→
08/03 18:14, 1月前 , 193F
控，但顯然沒有。再來是CI，你們Merge沒做test的話
08/03 18:14, 193F
→
08/03 18:14, 1月前 , 194F
，工程師們大多都是自己測爽了就上code，畢竟有太
08/03 18:14, 194F
→
08/03 18:14, 1月前 , 195F
多隱性的Bug在一開始是很難發現的，而工程師又很清
08/03 18:14, 195F
→
08/03 18:14, 1月前 , 196F
楚自己設計的程式邏輯，通常會無意識避開沒被考慮
08/03 18:14, 196F
→
08/03 18:14, 1月前 , 197F
進去的邏輯。
08/03 18:14, 197F
→
08/03 18:17, 1月前 , 198F
沒在前面時間寫unit test跟code review，那就是後
08/03 18:17, 198F
→
08/03 18:17, 1月前 , 199F
面花時間debug。老闆不是軟體出身不會懂，那你們真
08/03 18:17, 199F
→
08/03 18:17, 1月前 , 200F
的只能自求多福。
08/03 18:17, 200F
→
08/03 21:21, 1月前 , 201F
接案就是要快啊。接案通常沒在code review很正常，套句
08/03 21:21, 201F
→
08/03 21:21, 1月前 , 202F
sa 講的話，功能可以跑就好。你能做的就是跟對方溝通，
08/03 21:21, 202F
→
08/03 21:21, 1月前 , 203F
請對方要測過再commit。不然這真的無解
08/03 21:21, 203F
推
08/03 22:51, 1月前 , 204F
外包或支援就是看單子辦事 單子沒提到的當然就不算
08/03 22:51, 204F
→
08/03 22:51, 1月前 , 205F
這就是自研開發與外包支援的差異
08/03 22:51, 205F
→
08/03 22:52, 1月前 , 206F
這才是為什麼開單/開規格的人本應該把規格/測試寫清楚
08/03 22:52, 206F
→
08/03 22:52, 1月前 , 207F
所以才會有找外援反而更浪費人力的情況發生
08/03 22:52, 207F
→
08/03 22:53, 1月前 , 208F
因為原本可能對自己人可以模糊一點的需求必須改寫很清楚
08/03 22:53, 208F
→
08/03 22:54, 1月前 , 209F
規格裡面沒有限制效能資源的話
08/03 22:54, 209F
→
08/03 22:54, 1月前 , 210F
做的人浪費資源記憶體也只能默默自己事後改
08/03 22:54, 210F
→
08/04 18:27, 1月前 , 211F
這樣產一堆垃圾也算產量高嗎
08/04 18:27, 211F
推
08/05 06:42, 1月前 , 212F
不就你們做太慢?不然找他幹嘛
08/05 06:42, 212F
→
08/05 08:01, 1月前 , 213F
ku72板友說出答案了，老闆不懂的是穩定運作的東西不
08/05 08:01, 213F
→
08/05 08:02, 1月前 , 214F
要去搞它 不然開發team崩潰還要找人喔
08/05 08:02, 214F
推
08/05 16:43, 1月前 , 215F
把修 bug trace code等等工時統計出來 和其他專案結果
08/05 16:43, 215F
→
08/05 16:43, 1月前 , 216F
做比較 然後向上反應開發必需做更多審核考量 盡量反應
08/05 16:43, 216F
→
08/05 16:43, 1月前 , 217F
事實 不要針對人
08/05 16:43, 217F
→
08/05 19:33, 1月前 , 218F
艾倫
08/05 19:33, 218F
噓
08/06 12:58, 1月前 , 219F
怎辦，我看到反而是你們開發速度太慢也
08/06 12:58, 219F
→
08/08 21:12, 1月前 , 220F
code review是要看流程邏輯，以後交接才知道他在寫什麼
08/08 21:12, 220F
→
08/08 21:13, 1月前 , 221F
而不是針對有沒有空格，斷行怎麼斷，小細節在執著
08/08 21:13, 221F
→
08/08 21:15, 1月前 , 222F
其實老闆喜歡他是因為東西要先有，之後的再說
08/08 21:15, 222F
→
08/08 21:17, 1月前 , 223F
每個老闆個性不同，我就遇過要寫的快沒bug要有unit test
08/08 21:17, 223F
→
08/08 21:17, 1月前 , 224F
，要有test case報告
08/08 21:17, 224F
→
08/08 21:18, 1月前 , 225F
然後對空格排版又特別要求
08/08 21:18, 225F
→
08/09 09:48, 1月前 , 226F
這就是老闆要的吧，快速產出
08/09 09:48, 226F
→
08/09 09:48, 1月前 , 227F
你們沒辦法快速產出，他可以
08/09 09:48, 227F
推
08/10 00:30, 1月前 , 228F
這正常吧 先有畫面......？
08/10 00:30, 228F
推
08/10 12:15, 1月前 , 229F
說不定你以為有問題的情況才能為公司帶來最大的利益
08/10 12:15, 229F
推
08/14 10:34, 1月前 , 230F
他應該很擅長搞垮一間公司，先查查是不是商業間諜XD
08/14 10:34, 230F
‣ 更多 yestheway 的文章
文章代碼(AID): #1cgltSz- (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 8 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 yestheway 的文章
文章代碼(AID): #1cgltSz- (Soft_Job)