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

[Label (Panel)]

※ 引述《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
→ metaphysic:是同樣的code base,A與B分別開發各自的項目.
→ metaphysic:A的意思就是說,你得每一行告訴他怎麼改.
→ metaphysic:維護兩套source的原因就是考慮未來troubleshooting.
→ ZMittermeyer:我們是用svn去一起管的
→ metaphysic:如果A搞出一堆問題,可以從B的部份開始重寫A的部份.
→ metaphysic:如果A搞出一堆問題,可以從B的source開始重寫A的部份.
→ Label:其實我會建議A不要重寫，反覆的整合測試電爆B就可以了
→ Label:但是要讓主管或是PM知道是誰在拖進度
→ metaphysic:還有就是exception,log,message跟註解那些,A都不會做.
→ Label:打錯了，A 跟 B 弄顛倒
→ Label:雖然最後可能事情都還是B要來收尾
→ metaphysic:電爆B? B等很久了.誰電誰? 其實電個肉腳很沒意義.
→ Label:但至少要讓上面的看到是誰的問題
→ metaphysic:有時候重寫真的比較快,這種事我做過.
→ Label:B不電A的話，B會多作1-2人份的工作....
→ metaphysic:是會多做事,最好的方法就是把A踢出專案.
推 luciferii:其實，就算B電了A，大概也不會有任何改變。
→ luciferii:人不會因為被電就突然變強。
→ metaphysic:多加人是要幫忙解決問題,不是來製造問題的.
推 metaphysic:維護兩套source還有一個原因:釐清問題.
→ metaphysic:否則程式有問題時,A會說是因為B的部份有問題.
→ metaphysic:但是哪裡有問題又說不出來...
→ metaphysic:有時是,A指出的問題根本不是問題.
→ metaphysic:比如code原本支援3種ic,分別#define 1,2,3
→ metaphysic:B多加進兩種ic, 分別#define 4,5 結果A說這樣會有問題.
→ TonyQ:多加人本來就是會增加一定程度的問題 , 1+1 並不等於 2 .
推 kerickuo:1+1 如果還是大於等於 1 就要偷笑了 XDDDD
→ kerickuo:加的人有問題的話，大部分是讓原本產值為1的人產值變小..
推 phantom400:基本上會讓你想電想釘的人 不會對專案進度有正向的幫助
推 metaphysic:基本上電人釘人沒什麼樂趣,get out最好.
推 metaphysic:讓主管知道誰在拖進度又如何呢?主管看的是整個team.
→ Label:讓sponser知道這人是OJT不能算工時，另外還要再找個人進來
→ Label:如果delay不能因為這樣不給你們獎金或績效
→ Label:因為你們Team的人力本來就不足
→ Label:不釘人就少了讓他成長的機會，Team上也少了個增加戰力的機會
→ Label:過了一年多還是一個人做兩個人的事，遲早會有人不爽想辭職
→ Label:業務單位也會認為說怎麼你們研發單位這麼久了效率還這麼差
→ Label:當然這些應該是PM或Functional Manager的責任
→ Label:他們應該要掌握這些事情，知道有哪些人能力不行
→ Label:然後做些改善的對策