[閒聊] 被拖累的感覺...

看板Soft_Job作者 (免洗ID)時間17年前 (2008/09/26 22:54), 編輯推噓24(24推 0噓 33→)
留言57則, 19人參與, 最新討論串1/1
在一個 team 裡面一定會有些能力比較弱的人對吧? 最近程式老是出事，攤開一看都是一些不該有的錯誤， 某人負責的部分老是出錯，修也修不完，修了 A bug 出現 B bug，修了 B bug 出現 C bug 和尚未發現的 D、E、F bug... 寫程式習慣又很糟糕，一下忘記 free()，一下忘記 fclose()， 再不然就是不檢查 function return 的 error，直接一路 go 下去... 再三叮嚀寫完要做好測試，結果他自己都測不出來，通常都是 被其他人測出來，不然就是等到客戶發現才知道又出錯... team 裡面大家感情都還不錯，實在不知道怎麼跟他說。 大家有碰過這種情形嗎? 不知道各位都是怎麼看待這種情況? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 125.225.146.199
→
09/26 22:54, , 1F
抱歉使用免洗 ID，因為我 team 裡也會上來看這個版..XD
09/26 22:54, 1F
推
09/26 23:07, , 2F
讓他包幾次老闆自然就會讓他消失了吧
09/26 23:07, 2F
→
09/26 23:12, , 3F
不然利用六日全team加班幫他code review 久了自然也會消失
09/26 23:12, 3F
推
09/26 23:37, , 4F
假裝不小心 把這篇文轉給team成員看怎麼樣
09/26 23:37, 4F
推
09/26 23:51, , 5F
感情還不錯，歡喜就好；態度不佳，就釘下去
09/26 23:51, 5F
推
09/27 00:06, , 6F
為他導入正式的週期性 code review
09/27 00:06, 6F
推
09/27 00:19, , 7F
修A Bug出現B Bug?這比較像是沒想清楚就動手寫的感覺~如果
09/27 00:19, 7F
→
09/27 00:20, , 8F
有想清楚就不應該會有這種狀況~這根本是在補破洞~防這防那
09/27 00:20, 8F
→
09/27 00:22, , 9F
的~一點都不像在寫程式~乾脆在寫程式之前叫他把流程圖畫出
09/27 00:22, 9F
→
09/27 00:23, , 10F
來~還比看他的code去debug來得快...
09/27 00:23, 10F
推
09/27 00:56, , 11F
嚇到 還以為在說我 我離職了咩
09/27 00:56, 11F
推
09/27 14:08, , 12F
code review還不夠，記得加上lesson learn...
09/27 14:08, 12F
→
09/27 14:10, , 13F
寫出一個bug就交一份報告 討檢原因以供借鏡
09/27 14:10, 13F
→
09/27 14:12, , 14F
重複犯相同的錯 可以考慮訂立罰則 扣錢！ (充當公基金)
09/27 14:12, 14F
推
09/27 15:01, , 15F
樓上的做法簡單有效明暸 請問你還是學生嗎
09/27 15:01, 15F
推
09/27 15:07, , 16F
簡單明瞭的做法通常都對,但是不能用..
09/27 15:07, 16F
推
09/27 15:16, , 17F
扣錢...別來這招好嗎?程式工程師已經夠苦命了~哪天哪個又
09/27 15:16, 17F
→
09/27 15:17, , 18F
開先例~然後一堆老闆學~再加上一堆考驗你防呆功力的使用者
09/27 15:17, 18F
→
09/27 15:19, , 19F
...別鬧了~不適任就開除就好了~不懂留著幹嘛...
09/27 15:19, 19F
推
09/27 15:40, , 20F
我提的方法在某公司實際執行中 扣錢是違反某些rule才會
09/27 15:40, 20F
→
09/27 15:41, , 21F
執行上是拿錢出來請客吃吃東西 因為你出包害大家被拖累
09/27 15:41, 21F
→
09/27 15:44, , 22F
寫報告才是最累人的 五分鐘解bug 一個小時寫文件
09/27 15:44, 22F
→
09/27 15:45, , 23F
試過保證你不會輕易犯錯！
09/27 15:45, 23F
推
09/27 16:38, , 24F
誰寫的軟體沒有bug? 一個bug就要寫報告我看專案也不用
09/27 16:38, 24F
→
09/27 16:39, , 25F
做了 軟體寫出來就是要測 才知道問題在哪裡 所以才需要
09/27 16:39, 25F
→
09/27 16:39, , 26F
測試人員 我會很感謝測試人員幫我找出bug 但如果改採這
09/27 16:39, 26F
→
09/27 16:40, , 27F
方式 會變成程式人員怨恨找出bug的人 反而是惡性循環
09/27 16:40, 27F
推
09/27 17:00, , 28F
大推樓上
09/27 17:00, 28F
推
09/27 20:50, , 29F
程式工程師:搞定了!測試完成!功能正常無Bug!
09/27 20:50, 29F
→
09/27 20:50, , 30F
客戶:ㄜ...那個功能我不要了~可以改成別的嗎?
09/27 20:50, 30F
→
09/27 20:51, , 31F
程式工程師: 囧rz... Orz...
09/27 20:51, 31F
→
09/27 21:41, , 32F
做出來的不要，總比要的做不出來好～～～
09/27 21:41, 32F
推
09/27 22:07, , 33F
andymai說到重點 辛苦完成的功能被客戶一句話say goodbye
09/27 22:07, 33F
→
09/27 22:07, , 34F
尤其客戶不可能知道他以為很簡單的功能 其實很難改 唉~
09/27 22:07, 34F
推
09/27 23:37, , 35F
用B的方法 大概一兩周我就離開了
09/27 23:37, 35F
推
09/27 23:41, , 36F
自己測不出問題是公司SE教育訓練問題；其它人測出問題是公司
09/27 23:41, 36F
→
09/27 23:42, , 37F
release機制出問題；到客戶端才出包是測試人員要扛的；所以
09/27 23:42, 37F
→
09/27 23:42, , 38F
這個問題不只是工程師再教育或直接開除的問題了...
09/27 23:42, 38F
→
09/27 23:44, , 39F
工程師沒有寫好，release的人就要盯、要教，所以有權利
09/27 23:44, 39F
→
09/27 23:45, , 40F
release版本的人至少要有一定的程度，真正的強者不是code寫
09/27 23:45, 40F
→
09/27 23:46, , 41F
多短、多漂亮…就小弟的認知，Debug能力才是工程師的重點..
09/27 23:46, 41F
推
09/27 23:48, , 42F
所以原PO會有被拖累的感覺自己心態也要調整一下..
09/27 23:48, 42F
推
09/28 09:47, , 43F
重點應該是 怎樣改掉這位程式人員不良健忘習慣
09/28 09:47, 43F
→
09/28 09:48, , 44F
看起來就是一再的犯一樣的錯誤
09/28 09:48, 44F
推
09/29 01:02, , 45F
我遇過這種狀況，如果你不是頭頭，最好的辦法是可以反饋這
09/29 01:02, 45F
→
09/29 01:02, , 46F
情況給上頭的人，由他去決定，你就專心作你該作的。
09/29 01:02, 46F
→
09/29 01:03, , 47F
我之前的主管還好會很關心專案進度，常常會來詢問，所以反
09/29 01:03, 47F
→
09/29 01:05, , 48F
應後，主管自己做出了決定，停止繼續流血的狀態。
09/29 01:05, 48F
推
09/29 08:39, , 49F
這種事不應該由工程師扛，應算是主管的組織問題吧?
09/29 08:39, 49F
推
09/29 12:50, , 50F
工程師包 Coding+測試工程師+matain系統
09/29 12:50, 50F
→
09/29 12:51, , 51F
最好0 bug，一切都在4天內要完成..
09/29 12:51, 51F
推
10/01 00:48, , 52F
我舉的方法果然很讓工程師反彈，那陣子大家心裡都很幹
10/01 00:48, 52F
→
10/01 00:50, , 53F
尤其被罰拿錢出來請客的更是不爽 (我只有寫寫報告而已)
10/01 00:50, 53F
→
10/01 00:51, , 54F
但之後自己再寫code真的小心多了，那些lesson learn也
10/01 00:51, 54F
→
10/01 00:52, , 55F
也是一種經驗分享，把自己如何犯錯及避免的方式列出來
10/01 00:52, 55F
→
10/01 00:53, , 56F
一些雞毛蒜皮的問題不會有人叫你寫的...
10/01 00:53, 56F
推
10/01 00:57, , 57F
上個公司是很一板一眼的管理風格，所以才會弄出這招來
10/01 00:57, 57F
‣ 更多 WashFreeID 的文章
文章代碼(AID): #18tFURHI (Soft_Job)