作者:
abstract3 (abstract3)
2019-05-14 17:03:56跟Partner合寫一個A+B的功能
A+B又可分為A和B, 我負責A他負責B
總之就是A功能做完後產生的output要變成B的input
專案前期我說我可以負責合成部分, 也就是A+B的整合
整合期間我做得事就是確保A所產生的種種參數都是B要的 然後又因為B用了很多全域變數（歷史原因）, 造成合成時諸多困難
這些我覺得都還好 就只是要多花時間把B的function和variable調整一下
之後 我在測試合成結果（A+B）時
發現結果不符合期待
究其原因是B所要求的參數, A沒有給
但奇怪的是 A沒給指定參數 B卻可以跑且產生結果(只是不合理) 請問這樣誰的問題比較大?
再來 現在要修改合成後的東西（A+B）讓結果符合期待
討論結果是B的function要做更動
但對方覺得B要改得東西太多了 幾乎是全改B
所以不是很願意改
反而要求我（因為我當時說可以負責合成部分）去研究B的部份並做修改, 但B幾乎99.9%都是對方寫
首先我要花大量時間理解對方的邏輯
再者我做修改可能也不及對方做修改來得有效率且兼顧正確性
請問這樣的要求合理嗎
是否我當時不該說我可以弄合成
謝謝
作者: ericthree (如果 她這樣動人) 2019-05-14 17:15:00
B的input少給 是你沒做好還是他當時沒講?
要看當初怎樣談的 參數怎樣丟到b然後出來結果是怎樣我之前開接口給同事用的時候 會先看一下對方風格除非合作很久了 不然我很不喜歡這種只有一開始講然後就直接到驗貨的時候才見真章的東西 容易白工
作者: ESRI99 (炎涼) 2019-05-14 17:30:00
當初架構怎麼寫的?不會只是口頭吧?
作者:
feeya (24 August 升格為鄉民)
2019-05-14 17:53:00input output 交接最好是用純文字檔來溝通你多做個txt output 對方多做個txt read就好了
你的問題比較大 給B的input給錯了 他本來就不可能得出正確結果，B的程式沒有做防禦那是他的事，但至少他如果吃到正確的input就能產出正確的output的話(?) 也算能交差了至於要你去看B的module 我是覺得滿奇怪的啦....是說為啥你少給input 卻要改B的東西啊....
你的任務是"確保A所產生的種種參數都是B要的"，所以以目標導向的管理思維，你負責是合理的
作者:
xxi511 (少北)
2019-05-14 18:28:00你讓A多給不行嗎？
參數是你沒給，整合是你的工作，你負責合理阿！比較奇怪的是如果 B 吃到正確的參數就可以正常運作，為什麼不是讓 A 去補產生這個參數丟過去，而要大改 B 的程式碼？
87%是程式global variable滿天飛改不動了吧XD
作者:
loadingN (sarsaparilla)
2019-05-14 18:54:00學生專案還有歷史原因...
作者:
ckvir (ckvir)
2019-05-14 18:59:00你就改code增加實力啊 反正學生寫的應該也沒多複雜
作者: abraxas (Abr.) 2019-05-14 19:06:00
他寫得爛，但那塊是你負責的，所以是你的鍋。問題點你又只說得出某個原因，那還能說什麼？
作者:
chuegou (chuegou)
2019-05-14 19:21:00未經討論就修改介面時 討論的重點就應該是誰要吞下去
作者:
sxy67230 (charlesgg)
2019-05-14 19:26:00口頭上描述的話，那責任歸屬是誰你也沒辦法說清楚，input、output沒說清楚的情況下，那就是整合那方要背鍋
都已經定好protocol 當然要遵守 該給的output要給就好
作者:
sxy67230 (charlesgg)
2019-05-14 19:32:00而且你整合的，B大可以說整合的是你，我不知道你整合後怎麼改，到最後還是只有你能改。當作學教訓。任何專案啟動前，就該用文件白紙黑字寫清楚，你的系統要吃什麼intput、吐什麼output，對方要吃什麼吐什麼輸出，細節不必一開始就描述的很詳細，但架構要有，中途要修正也是先修正文件可以用google doc把你們的專案文件做雲端同步，多人協作可以追蹤大家修改的內容，還可以發送通知標記對方
作者:
jyunwei (jyunwei)
2019-05-14 19:57:00左轉男女版(？)
沒有事先要求的話B可以跑沒什麼不合理(預設參數後面我就不曉得對方在要求啥毀了
作者:
loadingN (sarsaparilla)
2019-05-14 20:22:00學生時代，很多阿宅都只會自幹又難溝通，你改的動就自己改，不然拖下去真的會氣死
作者:
stkoso (Asperger)
2019-05-14 20:37:00這是開始學test-driven develop的好時機你現在該做的不是找戰犯 而是試著從中學到教訓
作者:
nevak (^o^)
2019-05-14 20:43:00學生時期除了學技術，更重要的事學習與人相處和溝通啊，孩子
test case要訂啊 interface也要訂啊 最重要的設計階段會影響後來修改難易度 現在這情況你的責任比較大
作者:
testPtt (測試)
2019-05-14 20:45:00沒有先一起確認宣告再實作常常會做白工 整合一開始就要做
B的code爛歸爛 bug仍是因你而起的 你要負責收這設計不完全 溝通也不完全的鍋
作者:
sxy67230 (charlesgg)
2019-05-14 21:02:00我以為板控是每個工程師都要會基本工的說......至於interface跟test case，其實在大型專案，尤其需求不明確，但有時效的專案。通常可以訂個大概就好，但要隨著專案補齊文件。做文件做越詳細的好處是你日後來看會變得很容易，畢竟人還是很健忘的。我自己是習慣不管簡單還是難的專案或是作業都做一下文件，以後看起來就是很漂亮，也可以當作品面試使用。
作者:
idok (idok)
2019-05-14 21:14:00我覺得你一開始A不給input不太對 但溝通感覺問題更大
作者: hidog (.....) 2019-05-14 21:36:00
一般來講至少會有email討論界面吧....稍微有點規模的公司都會要求寫開發文件了 沒文件也要有信件
每次看PTT都有種平行世界的感覺，現在一堆公司打著敏捷開發的口號不寫文件吧...
作者: swhss 2019-05-14 22:47:00
敏捷開發又不寫文件，會容易失焦，即使完成了，接手維護的人也會很慘
A的問題卻去追究B，你覺得合理嗎？至於什麼原因不用知道，就是A很偉大不是B揹鍋就是你揹鍋，問題在於你的心態
作者: lukelove (午睡) 2019-05-15 00:15:00
這種很常見啦, 老闆就是要看結果, 跨team溝通總是要有人扛糞 一直追, 兩邊都耍屌還是要追,不然就A+B+你一起吃屎
作者:
molopo (mmm)
2019-05-15 00:36:00錢有下來 能力上去 騎驢找馬 管理有問題的公司 根本不值得賣命
如果你擅自變動輸出格式本來就有問題，雖然對方不能溝通問題很大，並且那個部分到底多紙糊...
作者:
BignoZe (BignoZe)
2019-05-15 01:57:00整合的人通常能力是最強的 一開始就要不斷關注兩邊可能發生的問題點 不斷修正方向 不是等到最後開天窗才在說這算誰的
5000 行是啥鬼我一份.py 如果超過 100行 都會被主管說太大
「 B的input少給 是因為某個其他原因, 導致我以為不需要這個input, 而我以為對方會知道」，最後不就是你自以為並在沒知會對方的情況下擅自更動了最初你們說好的規格？改B不改A，不會87%都是你的意思吧？ 說不定對方還覺得明明是你A少給當初說好參數，為什麼到頭來是他那份要大改？
作者:
mathrew (Joey)
2019-05-15 06:44:00同意樓上
作者:
sxy67230 (charlesgg)
2019-05-15 07:58:00沒有敏捷就不用寫文件溝通這回事吧？敏捷是指盡可能不去寫太多不必要的文件，但沒有不寫文件這回事。工程師之間合作本來就溝通、板控、文件缺一不可，溝通是協調彼此的架構，板控避免有人脫序，文件是強化溝通（不是每個需求都是簡單溝通大家就能理解的，相同的任務大家理解的方式可能就是有差異）
作者:
TuCH (謬客)
2019-05-15 08:08:00在寫一個C 做AB之間的轉換如何？ A->C->B
作者:
y3k (激流を制するは静水)
2019-05-15 08:21:00就菜而已 看是要給文件或由你去實作中間介面給他們用
作者: s06yji3 (阿南) 2019-05-15 08:26:00
你的問題比較大，因為你沒給指定的參數
作者:
deray (Deray)
2019-05-15 09:17:00一樣辣雞 不分上下
作者: ericthree (如果 她這樣動人) 2019-05-15 09:29:00
另外 什麼認為不用給參數以為他也知道…有疏失認錯就好了 好好講他可能還會幫你
作者:
zased (我只是上PTT查資料)
2019-05-15 09:32:00都沒經驗 就不要隨便指責別人了 感覺學會你不會的東西
感覺兩條路 你補該給的變數給B 他也去改他該改的或者 你們需要交紙本告報之類的要有人去弄 你再協調一個人去搞其他工作 一個人去把Ｂ搞好
作者:
nelley (名字：大便王)
2019-05-15 11:13:00規格書沒定之前不要開工寫code是常識阿...
作者:
testPtt (測試)
2019-05-15 11:36:00看起來像A給的參數要B產生出來 所以要改B
去找本"當責"的書來看，權責劃分分清楚來台灣人就老是要用講的，出問題時就推來推去
作者:
Jichang (C.C.Lemon)
2019-05-15 17:27:00感覺 B 有問題 B Input 不對 Output 也不對 當然是改 B..
作者:
deray (Deray)
2019-05-16 09:37:004 滾
作者: rocwild (外國死小孩) 2019-05-16 09:53:00
B出現了喔你們要不要現實生活中面對一下？
作者:
NonAir (宣)
2019-05-16 11:22:00下去修練
作者:
iamshiao (CircleHsiao)
2019-05-16 12:51:00你就負責整合，改規格不 sync，假設對方自己要知道，最後導致對方模組要大改還要吞下去，然後所有你有責任的地方都用「某個原因」這種講法避重就輕，通篇看下來就是你的問題
作者:
ILYY (毅力)
2019-05-16 16:26:00你不就負責整合的 還想怪誰
作者:
brucetu (sec)
2019-05-17 03:20:00"但奇怪的是 A沒給指定參數 B卻可以跑且產生結果"意思是B把那個參數hard code, function B沒有要求那個參數嗎? 那就是不符一開始談的spec了