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

看板Soft_Job (軟體人)作者 (Terry)時間3月前 (2024/08/01 20:39), 3月前編輯推噓9(10154)
留言65則, 9人參與, 3月前最新討論串2/8 (看更多)
※ 引述《yestheway (LKK)》之銘言: : 大家有沒有遇過這樣工程師… : 我們公司最近在開發新的專案,找了一位新來的工程師幫忙一起做。這個人Coding速度真 : 的很快,交給他的功能很快就能做出來。每個sprint下來,他也一直不停的接新ticket和 : 開發新東西。 : 最近這個新專案終於要上線了,結果QA卻測出了一大堆bug!!由於數量真的太多了,但 : 又為了承諾客戶如期上線,所以只好把我和其他2個工程師也叫來,一起昴下去幫忙解bug : … 我也很好奇,怎麼你們不一開始就做呢? : 結果不去看還好,一下去看他裡面的code,真的是非常可怕…又臭又長像流水帳一樣,結 : 構也是亂七八糟,很多邏輯明顯沒有想過或設計過硬幹去寫出來,沒有任何彈性和維護性 : ,大家花了非常多時間再改他的程式,真的改的非常辛苦... 這種code chatgpt 是可以代勞的,大概也就是哪樣的光景。 為何你們不join? : (對…我們為了趕這個專案,完全skip code review、skip unit tests 等等。二來 這 : 新專案相對獨立,不影響現有系統。所以他commit 什麼 就merge什麼,鬧得今天這下場 : 。我們的例子,正好回應前幾篇某些人質疑為何要code review......) : 最後產品雖然如期上線,但這下好了,老闆和PM現在超喜歡這個工程師,後面很多v2 要 : 衍生的新功能,都要叫這位工程師來主導開發… : 我們幾個幫忙「收爛攤子」的人,聽到真的有種不好的預感…一來害怕又有更多有問題的 : 程式被他寫出來,後面又要花更多時間來修改;二來有種功勞你在接,爛攤子我們在收的 : 感覺… : 我們原本找主管說這些問題,但目前公司大老闆想正積極開發這項產品,他們只希望快點 : 見到結果,似乎也不太在乎原有的開發流程了,只想先快點把東西生出來,給客戶demo… : 各位如果面對這種情況,和這樣的工程師該怎麼辦?公司想快速看到成品,找了一個產出 : 快的人,雖然短期快速看得到成果,但卻後患無窮… 這種故事就真的很有趣。 但這位神人在做時,你們在做什麼? 為何已經趕成這樣了,他好不容易寫好,哪你們改他的同時有CODE REVIEW 嗎? 有: 誰REVIEW? PM? 老闆? 神人? 還是互看? 這不就很神? 有空改寫有空測,還有空 REVIEW,還可以用更短的時間完成且沒BUG,這絕對是台灣之光。 沒: 整篇是想表示你們很神? 因為他寫到到快DEAD LINE 了,結果你們可以在這個 更短的時間,將他的重寫完,還不用review。神囉..... 還真的是鬼月到講鬼故事。 至於code review 囉....你是知道怎麼做? IEEE 1028-2008 lists the following review types:[6] Management reviews Technical reviews Inspections Walk-throughs Audits 還是你只是 Software peer review? 正式同行評審的程序會定義參與者特定的角色, 進入評審及離開評審的品質準則,在同行評審程序中要確認的軟體度量。 在檢查過程中,會有以下的角色。 作者:建立待檢查工作文件的人。 主持人:領導檢查流程的人,主持人規劃檢查流程,並且進行協調。 朗讀者:朗讀整份文件的人,一次讀出一部份,其他的檢查者會指出有缺陷之處。 記錄:在檢查過程中記錄大家找到缺陷的人。 檢查者:檢查工作文件中是否有缺陷的人。 檢查流程中的各階段包括有:計劃、簡介會議、準備、檢查會議、修正及追蹤。 以上中文來自WIKI,和英文WIKI 一致。 工程,還是以結果論英雄。 偏偏由一票沒programming 背景的人,發明了一票"方法",讓哪些 傻傻的programmer 去跟,還有人將他們當神拜。 不管agile, code review, 等的源頭,都是沒/沒什麼專案實績的人發明的。 真的除了人月神話。這本書還有20th review 版。 -- open source projects: https://github.com/terrylao/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.141.69.61 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1722515974.A.C71.html ※ 編輯: Lordaeron (220.141.69.61 臺灣), 08/01/2024 20:43:37 ※ 編輯: Lordaeron (220.141.69.61 臺灣), 08/01/2024 21:37:16 ※ 編輯: Lordaeron (220.141.69.61 臺灣), 08/01/2024 21:52:43

08/01 22:01, 3月前 , 1F
你說這些每個人都知道…這麼說好了 就像是交通規則,大
08/01 22:01, 1F

08/01 22:01, 3月前 , 2F
家也都知道,但當你老闆對你快馬加鞭,要你闖紅燈、超
08/01 22:01, 2F

08/01 22:01, 3月前 , 3F
速,要你十分鐘到達目的地時,你還停下禮讓行人嗎…
08/01 22:01, 3F

08/01 22:53, 3月前 , 4F
這不就好了,神人啊...我只知越急的寫得越爛
08/01 22:53, 4F

08/01 22:53, 3月前 , 5F
要是搞到天天加班就是專產垃圾了,但不包括神人。
08/01 22:53, 5F

08/01 23:40, 3月前 , 6F
忘了,闖紅燈害人害己。就算是開救護車也不一定安全。
08/01 23:40, 6F

08/02 09:09, 3月前 , 7F
這些google就找得到的教科書理論和工成流程都很好,但
08/02 09:09, 7F

08/02 09:09, 3月前 , 8F
除非你今天是老闆,否則很難有公司讓你完全照著最新
08/02 09:09, 8F

08/02 09:10, 3月前 , 9F
最完美的流程走。你可能工作經驗不是很多,看得還比
08/02 09:10, 9F

08/02 09:10, 3月前 , 10F
較單純,多工作幾年,你就會理解現實和理論往往很難並
08/02 09:10, 10F

08/02 09:10, 3月前 , 11F
行…
08/02 09:10, 11F

08/02 09:22, 3月前 , 12F
不是阿,回文你都能理解現實與理論差距
08/02 09:22, 12F

08/02 09:22, 3月前 , 13F
那你怎麼不能理解新人為了時程只能交爛Code
08/02 09:22, 13F

08/02 09:22, 3月前 , 14F
的這件事?你也很奇怪,不怎麼抱怨老闆
08/02 09:22, 14F

08/02 09:22, 3月前 , 15F
反而花篇幅抱怨趕出結果的新人
08/02 09:22, 15F

08/02 09:22, 3月前 , 16F
你還不如多把篇幅著墨在阿新人就是故意擺爛
08/02 09:22, 16F

08/02 09:22, 3月前 , 17F
從新人變老人換個屁股腦子也跟著換了是嗎?
08/02 09:22, 17F

08/02 10:03, 3月前 , 18F
這隻就沒料廢文ID你們跟他認真啥0.0..
08/02 10:03, 18F

08/02 10:21, 3月前 , 19F
我們並沒有人去趕這個新人,甚至怕他開發時間不夠,才
08/02 10:21, 19F

08/02 10:21, 3月前 , 20F
省去了這些unit test, integration test, code review
08/02 10:21, 20F

08/02 10:21, 3月前 , 21F
等等工作。光是不用寫測試,已經多出很多時間了!
08/02 10:21, 21F

08/02 10:21, 3月前 , 22F
大家雖然都有自己工作要忙,但能夠幫的都做到位,有應
08/02 10:21, 22F

08/02 10:21, 3月前 , 23F
必答,有技術問題也是一步步帶。就算時間再短,你是不
08/02 10:21, 23F

08/02 10:21, 3月前 , 24F
是在敷衍應付,還是有用過心,尤其是很多結案的,真的
08/02 10:21, 24F

08/02 10:21, 3月前 , 25F
不要以為沒人看得出來欸......
08/02 10:21, 25F

08/02 10:58, 3月前 , 26F
有料的廢文王B0988698088,先回我上一篇吧。
08/02 10:58, 26F

08/02 10:59, 3月前 , 27F
原作先生,你就針對我的問題回一篇即可。
08/02 10:59, 27F

08/02 11:00, 3月前 , 28F
unit test 做不做根本沒人在意,SIT 做就可以反應問題
08/02 11:00, 28F

08/02 11:01, 3月前 , 29F
而原作先生,你不用質疑我的工作經驗。這你挑不來的。
08/02 11:01, 29F

08/02 11:24, 3月前 , 30F
沒有趕新人 然後通篇在幹樵新人寫的不合老人的習慣
08/02 11:24, 30F

08/02 11:38, 3月前 , 31F
你們沒在趕新人,所以這專案是沒時程壓力?
08/02 11:38, 31F

08/02 11:38, 3月前 , 32F
照原文看新人是來「幫忙」專案,怎麼幫到
08/02 11:38, 32F

08/02 11:38, 3月前 , 33F
被老闆、主管,委以重任V2功能給他做?
08/02 11:38, 33F

08/02 11:38, 3月前 , 34F
既然是「幫忙」你們怎麼搞到主導者看起來變新人
08/02 11:38, 34F

08/02 12:23, 3月前 , 35F
公司原本人手就吃緊了,就我所知,老闆承諾了客戶開發
08/02 12:23, 35F

08/02 12:23, 3月前 , 36F
這個專案,在這情況下,只好再徵個工程師來開發,而這
08/02 12:23, 36F

08/02 12:23, 3月前 , 37F
名新人也有過多年專案開發經驗,就讓他負責接下開發了
08/02 12:23, 37F

08/02 12:23, 3月前 , 38F
。之後就發生了我前面文章的故事…
08/02 12:23, 38F

08/02 12:23, 3月前 , 39F
我認為你可能想的太可怕了,事實上西方公司的團隊文化
08/02 12:23, 39F

08/02 12:23, 3月前 , 40F
,沒有這麼顯著的「老人」 「新人」上下關係或什麼壓榨
08/02 12:23, 40F

08/02 12:23, 3月前 , 41F
新人,我也在台灣工作過多年,我懂你在說什麼,但真的
08/02 12:23, 41F

08/02 12:23, 3月前 , 42F
不是那樣…大家都是平起平坐的同事關係。我們一起吃飯
08/02 12:23, 42F

08/02 12:24, 3月前 , 43F
時,也常關心他工作和生活狀況等,大家下班也是5點準
08/02 12:24, 43F

08/02 12:24, 3月前 , 44F
時走,不是你想的那個樣子…至於他的工作成果,就如前
08/02 12:24, 44F

08/02 12:24, 3月前 , 45F
文所說,又快又驚人XD…
08/02 12:24, 45F

08/02 12:42, 3月前 , 46F
除非你有辦法證明他的程式品質差到不如重寫 且同樣時
08/02 12:42, 46F

08/02 12:42, 3月前 , 47F
間內產出成果不如舊有開發模式 不然都是多講的
08/02 12:42, 47F

08/02 13:07, 3月前 , 48F
關係不差又平等 為啥不直接找他談 而是這邊diss品質差
08/02 13:07, 48F

08/02 14:03, 3月前 , 49F
就不能針對我的質疑回應就是了?我沒要你證明品質哦。
08/02 14:03, 49F

08/02 21:36, 3月前 , 50F
承諾也是可以跳票的,多的是在客人前面亂開支票的老闆
08/02 21:36, 50F

08/02 21:36, 3月前 , 51F
,反正那個案子不delay,先簽下來才有之後的事。
08/02 21:36, 51F

08/02 22:07, 3月前 , 52F
看你夠不夠力,不然被罰到倒賠是可能的。
08/02 22:07, 52F

08/03 00:16, 3月前 , 53F
08/03 00:16, 53F

08/03 00:17, 3月前 , 54F
這篇原 Po 就 csfgsj 分身啊,大家跟他認真啥
08/03 00:17, 54F

08/03 00:26, 3月前 , 55F
08/03 00:26, 55F

08/03 00:26, 3月前 , 56F
笑死
08/03 00:26, 56F

08/03 01:40, 3月前 , 57F
這就跟大家都在趕時間誰在看紅綠燈一樣吧 理論上看到紅燈要
08/03 01:40, 57F

08/03 01:40, 3月前 , 58F
停下來 但我在趕時間啊 所以我闖紅燈錯了嗎? 當然沒錯啊
08/03 01:40, 58F

08/03 01:40, 3月前 , 59F
你看拓海過彎不踩剎車用水溝蓋跑法不就得第一了? 所以我過
08/03 01:40, 59F

08/03 01:40, 3月前 , 60F
彎不踩剎車有問題嗎? 都是以成敗論英雄啦 時間在趕實在管
08/03 01:40, 60F

08/03 01:40, 3月前 , 61F
你什麼什麼紅綠燈啦
08/03 01:40, 61F

08/03 08:50, 3月前 , 62F
@CoNsTaR 你腦補的,可以繼續.
08/03 08:50, 62F

08/03 08:51, 3月前 , 63F
然後一群C++ GEEKS 在哪抱團。
08/03 08:51, 63F

08/03 09:02, 3月前 , 64F
然後"對於同事的coding style感到很感冒" 在哪抱著暖.
08/03 09:02, 64F

08/03 09:03, 3月前 , 65F
C++真的沒問題,真的是用的人的問題,但自己人就沒問題
08/03 09:03, 65F
文章代碼(AID): #1cgu86nn (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1cgu86nn (Soft_Job)