楼主:
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了