离岸错误修复


11

如果准雇主告诉您“由于开发人员讨厌修复错误,他们将错误修复外包了”,您会怎么想?您可能会担心什么?


1
开发人员讨厌修复错误吗?我认为他们更讨厌找到可靠的方法来重现该错误,这正是测试人员的目的。如果您将错误修复外包,则最好将整个开发团队外包。没有人比自己编写的人更了解代码。
罗布

1
听起来像一个可怕的主意。
Andres F.

1
@AndresF。+1。这将创造一个环境,使开发人员可以将垃圾丢在墙上,并希望它能坚持下去。如果不是,他们的问题不是吗?
MrFox 2012年

Answers:


25

解决我们自己的错误实际上使我们成为更好的开发人员。对我来说,这是一个非常愉快的时刻。特别是当它们被很好地报道时。

如果他们不喜欢修复错误,那么问题就出在其他地方。

我怀疑问题出在管理人员如何看待错误,或更糟糕的是,错误的设计决策和/或没有(单元)测试会导致错误修复。

外包错误修复可能会使情况更糟。

开发人员可能会想降低质量。谁在乎?一些海上家伙在那里清理他们的混乱。

直到离岸人员替换在岸人员为止。


大声笑,你想吓people人不要打扰
Aditya P

@Aditya:这里没什么吓人的,这正是我最后一位雇主正在发生的事情。离岸人员一直有足够的错误修复程序,他们的经理(对他来说是阿们)开始提供培训。一方面,他们足够好,可以开始简单的重构,清理等工作。与此同时,在总公司,一切都没有改变。我可以很容易地看到,在明年,离岸人员将完成大部分工作,总公司的人员也将完成……好……可惜的是他们没有看到火车的到来;-P
Newtopian'Apr

15

离开逃跑 ...快速,永不回头...

我曾在这样一家公司工作,他们认为他们很聪明,

  • 嘿,我们都有他们所有的错误,但是我们的前辈抱怨他们花费太多时间修复错误。

  • 让我们开设一个离岸办公室,让其他人来处理这个问题。

对于一个听起来听起来像是一个非常好的计划的经理,开发人员最终被释放来解决创建次佳事物的更有趣的任务!

......等等...

两年后,他们从总公司的5个开发人员团队转到了2个创建新东西的团队和30个发现并修复错误的团队。

您知道吗...错误修复团队正在苦苦挣扎,他们跟不上。

这使得“前辈”完全无法为自己的错误负责。更糟糕的是,由于一切都发生得太遥远,因此管理人员也没有意识到,并且代码质量从已经很糟糕的质量水平急剧下降了。

当我离开时,他们已经为臭虫修复者开设了两个办事处,他们仍然不能跟上现在唯一创建它们的开发人员。他们实际上认为这是因为新手不够聪明...

所以是的,从现在开始,如果一家公司说他们将其漏洞修复工作外包给了一家海外办事处,请相信我....我运行起来...很快。

这是纸袋管理方法。

站在铁路上,等待火车来临时,一看到火车,就将纸袋放在头上,然后……POOF ..火车不见了!魔法 !


9

让公司付钱给别人清理我的烂摊子听起来像是个好主意,除非期望我采用他们的“干净”代码并添加新功能。如果他们搞砸了,无法修复它,那么您将在调试调试程序。

由于他们不得不雇用额外的开发商而没有得到足够的补偿是不希望的。

如果您自己可以解决问题,则不得不花费过多的时间来教育其他开发人员会适得其反。

我的一部分感觉是,那些创造问题的人应该是那些解决问题的人,否则就没有动力避免首先制造错误。


6

开发人员是否不愿意从错误中学习?您是否可以在没有特定领域知识的情况下修复错误,外包合作伙伴是否拥有此知识?大多数时候,固定部分是最容易的,它花费时间的分析部分。在我看来,这是一个愚蠢的决定。


6

如果准雇主告诉您“由于开发人员讨厌修复错误,他们将错误修复外包了”,您会怎么想?您可能会担心什么?

我会跑得很远很远。开发人员总是,总是,总是有责任修复自己的错误。吃狗粮是良好工程的基本原则。

此外,错误修复同样重要,也许比开发更重要。我的意思是,开发是代码编写,测试和调试/修复。

我从这家公司得到的是,他们将错误修复视为第二类任务。这本身就很令人不安,我会高度质疑他们的工作质量(以及因此而来的工作环境)。更令人不安的是,他们将对他们而言是二等工作委托给离岸工人。那更令人不安。显然,他们的工程过程中包含着社会分层。

缺陷总是导致变更的根本原因,通常,错误是由引入变更的人负责的。谁比鼻祖更好地了解错误的性质及其解决方案?

如果它是在全球范围内委派的,那么如何确保原始作者可供离岸工程师使用?

他甚至有空吗,留下离岸工程师,除了积压的错误和截止日期之外,别无他物,但没有Metropole的支持?一个人可能希望执行哪种类型的错误修复?谁修复他的错误?是什么阻止Metropole的开发人员通过修正验尸来学习?

所有领域都有混蛋。在软件中尤其如此。由于这是不可避免的,因此您唯一的选择是与比您了解更多或做正确的混蛋一起工作。该公司似乎不符合该描述。

总之,逃跑。


2
“此外,错误修复同样重要,也许比开发更重要。” 我知道您在那儿的意思,但我要说的是:我无法理解任何这种二分法。错误修复是开发的内在基础。
丹·雷

1
@Dan-是的,您的陈述要正确得多。不存在这种二分法。
luis.espinal 2011年

4

他们是否真的希望一群离岸初级开发人员能够修复一堆高级开发人员代码?就像让护士仔细检查所有神经学家一样,并在他做错了的地方重做它。馊主意!


3

我会担心他们的员工实际上对他们正在开发的代码有多了解。
我也想知道为什么有足够的错误来证明这样做带来的额外成本的原因。我还要担心公司的长期发展,网上有很多文章声称这些公司即使在同一个行业中也对多个项目使用相同的代码。

修复损坏的代码是编写代码过程的一部分,它使您可以更好地了解6个月前的错误,因此,如果其他一些开发人员修复了错误,那么您将不会犯同样的错误。错误一次又一次发生?


3

这听起来有点像我以前的雇主,除了“准雇主”位。他们一直在让开发人员流失,失去太多支持现有产品,而又增加了法律法规变更所需的新功能(办公室收入的60%来自基于VB6的产品,而MS表示VB6运行时不会在将来的任何操作系统中分发,因此就像Vista出现时一样-疯狂地解决问题)。想要使公司很快上市的力量,所以他们正在让所有人都在渴望资源,以使资产负债表看起来比实际更好。因此,在海外聘用是接近市场的唯一途径。

根据我的经验,引述所说的是您的准雇主便宜。


+1有史以来最糟糕的工作。听起来他们没有将足够的收入用于项目。
Ramhound 2011年

除了“准雇主”位<LOL
Greg B,

我注意到“以前的雇主”一词。恭喜你
David Thornley

@ Ramhound,David,Greg,当我开始时这是一个更好的地方,我在12月底(5周年纪念后不久)离开了这个地方。自从我被录用以来,没有人被录用过。在过去的两年中,有6位开发人员退出了。最近一次离开的时间是11年。
Tangurena

3

这取决于它们“修复错误”的含义。如果这是在开发/测试周期内修复错误,那么这很奇怪,这是原始开发人员的工作。另一方面,如果它们表示已将发布产品的维护外包,那么这并不罕见,这不是我担心的事情。


好一点,没有人想到过这个角度。
Greg B

@Greg&Steve-老实说,我认为这并不重要。如果他们要修复发行版中的错误,如果开发人员不自行编写错误修复程序,那么这些修复程序如何合并到测试版本中。
Ramhound,2011年

如果将错误修复程序签入到源代码管理中,则其他团队可以轻松地将其合并到另一个分支中。没什么大不了的。
史蒂夫

尽管我只在应用程序是不再被积极开发但由于某种原因而需要保持功能的旧系统的情况下才真正批准这种情况,您还是提出了一个很好的观点。说一个完整的重写形式的新一代。
Newtopian

2

我的经验是,事实成立后聘请外部团队将花费与修复您自己的bug差不多的时间-需要加快它们的速度并将其引入开发过程。然后不断跟上速度。协调比编写代码难。


1

如果我要在代码库上工作,我想保证每个拥有提交特权的人都具有足够的能力。例如,这包括印度的很多人,但不包括通常被转移到的人。

而且,我的大多数错误都在代码的更复杂的部分中,而离岸程序员在应用错误修复之前最不可能理解这些错误。


1

实际上,某些公司在潜意识中存在着这一政策。我为外包商工作;我自己和我的同事比现场的人更熟练的程序员,他们要求我们教给他们如何使用工具等,但是另一方面,我们比他们更快地发现他们的代码中的问题。

通常,客户的程序员与至少一些用户物理上位于同一建筑物内,因此他们更有可能获得无法跨半球的上下文。我们发现它运作良好,对我而言,缺失的部分是他们没有在审查我们的代码,因此当合同完成时,他们可能会有一些意外或疑问,这不是由于我们方面的任何伪劣做法,而是由于您遇到的常见问题接管别人的项目。

无论如何,我很高兴在我们的情况下这不是官方政策,因此我认为这会侵蚀现场程序员,使他们只不过是BA。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.