问题在于LZ太急于和过于表现自己能力。不在其位，不谋其政，他写的代码，他自己对其负责，你没必要“帮他改错，重新整理代码”。如果你技术水平高到可以轻松加愉快地做到这些，那做了也无所谓，问题是你看的“想吐血”，那你就别看呗。
你只需要找到Bug，粗略分析一下，无需具体分析错在哪里并帮他改错（这正是你想吐血的原因）。告诉同事，这个测试用例没有得到期望的结果，错误可能出现在某个部分，然后让他自己去分析修改。
同事知道你的水平，如果他搞不定，自然会来找你，这时候你再出手。但是你也没必要玩命儿地去分析，争分夺秒地出活儿。该Pause就Pause，该喝Kaffee喝Kaffee。一天改一个Bug也没关系，反正是同事搞不定才来找你，他自己可能一天也改不好呢。
你可能会问那项目延期怎么办？那就让他延呗，你在这个项目中不是男一号，犯不上操那份心。上司知道出问题的是他的部分即可。如果上司意识到这个问题，任命你为男一号，那你再玩命也值得。
通常情况下，你想轻松加愉快地工作还是快马加鞭，呕心沥血，只取决于你自己，即使你是男一号。通常无论你怎么选，你的工资单没啥变化。
呵呵，你们公司Review的人可以和写代码的人一起改代码，QS不过关啊
tracywyt 发表于 2014-8-8 09:36
呵呵，你们公司Review的人可以和写代码的人一起改代码，QS不过关啊
要改的话都是2个人同时确认改动的内容后，再提交。至于用谁的用户提交到CVS，这个倒无所谓。。
本帖最后由 和路雪 于 2014-8-8 10:06 编辑
adgjl 发表于 2014-8-8 09:30
问题在于LZ太急于和过于表现自己能力。不在其位，不谋其政，他写的代码，他自己对其负责，你没必要“帮他改 ...
无所谓一号二号。一个人开发的内容，另一个人必须审核并且充分理解。
不然一个人离职了或者休假了出了问题很难解决。这是公司要求的。
我自己也要开发，他也必须为我做Review，但他一般找不出来错。
你说的办法我也想过，即只提出Bug，让他自己去解决。这样会导致，几天后他改了一堆东西，我又得重新看一遍。。那时候我已经忘了不少细节了。。这样还不如我一开是直接找到他，分析之后当场改掉来的快。。
另外软件缺陷的修复和发现，在开发阶段成本是最低的。。在交付后出了问题，找出缺陷的成本很高，压力也很大。而且查找缺陷很可能就是我和他两个人一起找，因为你不能当场确定是谁写的内容挂了。。
我还是宁愿在开发阶段把东西做好，不想频繁在客户那里救火。。即使最后不是我的责任，也会给我带来不少烦恼。
上面的好些都说了，让你不要过于自信，急于求成。除此之外，你老板信任的是他 而不是你， 反之，你对你的老板的信任也不如他对你老板的，
真要经受考验的时候，我估计也是他更比你更值得托付，考验并不是光在技术上的。等你真正成为公司的资产，你在发表单干的意见不迟。
R2D2 发表于 2014-8-8 10:41
上面的好些都说了，让你不要过于自信，急于求成。除此之外，你老板信任的是他 而不是你， 反之，你对你的老 ...
我没有想取代他或者怎么样。。只是不想成天干这种无聊的替人改错的事情。我还巴不得他是大牛，带着我玩，让我轻轻松松呢。。
即使是Teamarbeit也有分工吧，也不是2个人出一份代码吧，即使是出一个组件，也有分工吧，照我看，你只要完成你自己的那一份就行了，你也是职业人士吧，拿钱做事，不需要做义工，即使不赚钱也要赚吆喝吧，Vorwurf大可不必，但让老板注意你的努力也是需要的。
楼主的想法可以理解，搞计算机的都明白，我实习的时候的做法就是睁一眼闭一只眼，老IT的经验可能局限在几年以前的技术侧面，新事物立刻接受不太现实。
改动过大时，直接自己重新写，然后跟你说的A同事好好聊聊你为什么这么写。同事之间应该是互相交流，让别人理解你的想法是最重要的。而不是急于去把你的想法摆到更高的层面上去讨论。一切事情都要循序渐进的去操作。
R2D2 发表于 2014-8-8 10:51
即使是Teamarbeit也有分工吧，也不是2个人出一份代码吧，即使是出一个组件，也有分工吧，照我看，你只要完 ...
C程序挂了就整个进程崩溃了。在客户那里挂了，找问题能把你烦死。。你也不能当场确定因为什么原因挂了，即使有日志或者Core文件什么的，也不能百分之百当场定位原因。
总之就是崩溃了大家日子都很难过。。
和路雪 发表于 2014-8-8 10:05
无所谓一号二号。一个人开发的内容，另一个人必须审核并且充分理解。
不然一个人离职了或者休假了出了 ...
你现在做这些的目标是什么？踢走A换一个高手来？踢走A自己上位？
既然这小组是A负责，代码是否能按期完成，是他需要操心的事。你的任务是发现错误，给提示信息让他修改，至于什么时候能修改好，不需要多操心。如果一直出问题，A感觉压力太大，自己会走人的。要么总是出问题，老板自然会想到换人。