Re: [請益] 請問工作遇到問題，該問同事還是自己解決?

看板Soft_Job作者 (Panel)時間14年前 (2009/09/18 03:28), 編輯推噓6(6推 0噓 34→)
留言40則, 7人參與, 最新討論串6/12 (看更多)
※ 引述《metaphysic (多情應笑我)》之銘言： : 還有一次, B把程式寫好交給A要merge, : 為什麼讓A來merge? 因為A的部份還沒寫好. : A: 我不會merge. : B: 寫程式的人不會merge code? : A: 因為我不知道你改了哪些地方. : B: 誰會記得改過的每一行code? 你不會用比對軟體? : A: ... : 從此以後, B總是維護兩套source, 一套是有包含A的code, 一套沒有. 這樣有點奇怪，即使用比對軟體列出所有不同的點， 整合在一起時，誰也不能保證不會錯啊， 一旦有錯誤產生，troubleshooting的難度通常比同一個人用的還高。 同一個部門或者專案團隊最好是保持同一個版本的code會比較好。 養成好的習慣，慎用exception,log,message跟註解， 可以節省很多debug的時間。 甚至還能將潛在的bug在unit testing時期就先擋掉。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 219.71.95.11
→
09/18 03:30, , 1F
是同樣的code base,A與B分別開發各自的項目.
09/18 03:30, 1F
→
09/18 03:31, , 2F
A的意思就是說,你得每一行告訴他怎麼改.
09/18 03:31, 2F
→
09/18 03:33, , 3F
維護兩套source的原因就是考慮未來troubleshooting.
09/18 03:33, 3F
→
09/18 03:33, , 4F
我們是用svn去一起管的
09/18 03:33, 4F
→
09/18 03:33, , 5F
如果A搞出一堆問題,可以從B的部份開始重寫A的部份.
09/18 03:33, 5F
→
09/18 03:34, , 6F
如果A搞出一堆問題,可以從B的source開始重寫A的部份.
09/18 03:34, 6F
→
09/18 03:35, , 7F
其實我會建議A不要重寫，反覆的整合測試電爆B就可以了
09/18 03:35, 7F
→
09/18 03:36, , 8F
但是要讓主管或是PM知道是誰在拖進度
09/18 03:36, 8F
→
09/18 03:36, , 9F
還有就是exception,log,message跟註解那些,A都不會做.
09/18 03:36, 9F
→
09/18 03:36, , 10F
打錯了，A 跟 B 弄顛倒
09/18 03:36, 10F
→
09/18 03:37, , 11F
雖然最後可能事情都還是B要來收尾
09/18 03:37, 11F
→
09/18 03:37, , 12F
電爆B? B等很久了.誰電誰? 其實電個肉腳很沒意義.
09/18 03:37, 12F
→
09/18 03:37, , 13F
但至少要讓上面的看到是誰的問題
09/18 03:37, 13F
→
09/18 03:39, , 14F
有時候重寫真的比較快,這種事我做過.
09/18 03:39, 14F
→
09/18 03:39, , 15F
B不電A的話，B會多作1-2人份的工作....
09/18 03:39, 15F
→
09/18 03:40, , 16F
是會多做事,最好的方法就是把A踢出專案.
09/18 03:40, 16F
推
09/18 03:40, , 17F
其實，就算B電了A，大概也不會有任何改變。
09/18 03:40, 17F
→
09/18 03:41, , 18F
人不會因為被電就突然變強。
09/18 03:41, 18F
→
09/18 03:41, , 19F
多加人是要幫忙解決問題,不是來製造問題的.
09/18 03:41, 19F
推
09/18 03:53, , 20F
維護兩套source還有一個原因:釐清問題.
09/18 03:53, 20F
→
09/18 03:54, , 21F
否則程式有問題時,A會說是因為B的部份有問題.
09/18 03:54, 21F
→
09/18 03:56, , 22F
但是哪裡有問題又說不出來...
09/18 03:56, 22F
→
09/18 03:58, , 23F
有時是,A指出的問題根本不是問題.
09/18 03:58, 23F
→
09/18 03:59, , 24F
比如code原本支援3種ic,分別#define 1,2,3
09/18 03:59, 24F
→
09/18 04:00, , 25F
B多加進兩種ic, 分別#define 4,5 結果A說這樣會有問題.
09/18 04:00, 25F
→
09/18 07:52, , 26F
多加人本來就是會增加一定程度的問題 , 1+1 並不等於 2 .
09/18 07:52, 26F
推
09/18 07:54, , 27F
1+1 如果還是大於等於 1 就要偷笑了 XDDDD
09/18 07:54, 27F
→
09/18 07:55, , 28F
加的人有問題的話，大部分是讓原本產值為1的人產值變小..
09/18 07:55, 28F
推
09/18 12:16, , 29F
基本上會讓你想電想釘的人 不會對專案進度有正向的幫助
09/18 12:16, 29F
推
09/18 12:48, , 30F
基本上電人釘人沒什麼樂趣,get out最好.
09/18 12:48, 30F
推
09/18 13:16, , 31F
讓主管知道誰在拖進度又如何呢?主管看的是整個team.
09/18 13:16, 31F
→
09/18 22:18, , 32F
讓sponser知道這人是OJT不能算工時，另外還要再找個人進來
09/18 22:18, 32F
→
09/18 22:18, , 33F
如果delay不能因為這樣不給你們獎金或績效
09/18 22:18, 33F
→
09/18 22:18, , 34F
因為你們Team的人力本來就不足
09/18 22:18, 34F
→
09/18 22:27, , 35F
不釘人就少了讓他成長的機會，Team上也少了個增加戰力的機會
09/18 22:27, 35F
→
09/18 22:27, , 36F
過了一年多還是一個人做兩個人的事，遲早會有人不爽想辭職
09/18 22:27, 36F
→
09/18 22:30, , 37F
業務單位也會認為說怎麼你們研發單位這麼久了效率還這麼差
09/18 22:30, 37F
→
09/18 22:31, , 38F
當然這些應該是PM或Functional Manager的責任
09/18 22:31, 38F
→
09/18 22:32, , 39F
他們應該要掌握這些事情，知道有哪些人能力不行
09/18 22:32, 39F
→
09/18 22:32, , 40F
然後做些改善的對策
09/18 22:32, 40F
‣ 更多 Label 的文章
文章代碼(AID): #1Aiet7vu (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 6 之 12 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共12篇)
‣ 更多 Label 的文章
文章代碼(AID): #1Aiet7vu (Soft_Job)