해외 버그 수정


11

장래의 고용주가 "개발자가 버그 수정을 싫어하기 때문에 버그 수정을 아웃소싱했다"고 말하면 어떻게 생각하십니까? 당신의 관심사는 무엇입니까?


1
개발자는 버그 수정을 싫어합니까? 테스터들이 버그 를 재현 할 수있는 신뢰할만한 방법을 찾는 것이 더 싫다고 생각합니다 . 버그 수정을 아웃소싱하는 경우 전체 개발 팀을 아웃소싱 할 수도 있습니다. 코드를 직접 작성한 사람뿐만 아니라 코드를 이해하는 사람 은 없습니다 .
Rob

1
끔찍한 생각처럼 들립니다.
Andres F.

1
@AndresF. +1. 이것은 개발자들이 벽에 쓰레기를 던져 버릴 수있는 환경을 조성 할 것입니다. 그렇지 않다면 그들의 문제가 아닌가?
MrFox

답변:


25

우리 자신의 버그를 수정하면 실제로 우리는 더 나은 개발자가 됩니다. 그리고 그것은 꽤 즐거운 순간입니다. 특히 그들이 잘보고 될 때.

그들이 버그를 수정하고 싶지 않다면 문제는 다른 곳에 있습니다.

문제는 경영진에 의해 버그가 어떻게 인식되는지 또는 나쁜 설계 결정 및 / 또는 (단위) 테스트가 아니 어서 버그 수정이 고통 스러운지를 의심합니다.

아웃소싱 버그 수정은 아마도 상황을 악화시킬 것입니다.

개발자는 품질 저하를 원할 수 있습니다. 무슨 상관이야? 일부 해외 사람들은 엉망을 정리하기 위해 거기에 있습니다.

해외 사람들이 해외 사람들을 교체 할 때까지.


롤 당신은 사람들 dontcha의 지옥을 놀라게 좋아
아 디트 P

@Aditya : 여기서 무서운 것은 없습니다. 이것이 바로 나의 마지막 고용주에서 일어나는 일입니다. 근해 사람들은 항상 버그 수정이 충분했고 관리자 (아멘에게)가 훈련을 시작했습니다. 어느 시점에서 그들은 간단한 리팩터링, 정리 등을 시작할 수있을 정도로 좋아졌습니다. 본사에서는 그 동안 아무것도 바뀌지 않았습니다. 나는 아주 쉽게 다음 년 이내에 해외 녀석들이 기차 오는 ;-P 보지 않았다 ... 음 ... 너무 나쁜 작업 및 본사들 대부분 다할 것을 볼 수 있습니다
Newtopian

15

휴가는 , 도망 빠른 ... 다시 쳐다 보지도 않을 ...

나는 그런 회사에서 일했고 그들은 똑똑하다고 생각했습니다.

  • 야, 우리는 모든 버그를 가지고 있지만 우리 선배들은 버그를 수정하는데 너무 많은 시간을 소비한다고 불평한다.

  • 해외 사무소를 개설하고 다른 사람들이이 문제를 해결하도록하겠습니다.

정말 좋은 계획처럼 들리는 관리자를 위해 개발팀은 마침내 다음으로 최고의 것을 만드는 더 흥미로운 과제를 해결했습니다!

호 ... 잠깐만 ...

2 년 후, 그들은 본사에서 5 명의 개발자로 구성된 팀에서 새로운 것을 만들어내는 2 명의 팀과 버그를 찾아 수정하는 30 명의 팀으로이 모든 것을 처리했습니다.

당신은 무엇을 알고 있습니다 ... 버그 수정 팀은 어려움을 겪고, 그들은 유지할 수 없습니다.

이로 인해 "노인"은 자신의 실수로 완전히 계산할 수 없었습니다. 최악의 경우, 모든 것이 지금까지 일어났기 때문에 경영진은 인식하지 못했고 코드 품질은 이미 심연의 품질 수준에서 매우 빠르게 급락했습니다.

내가 떠났을 때 그들은 이미 버그 픽스 너를 위해 두 개의 사무실을 더 열었고 여전히 그것들을 만드는 유일한 개발자 뒤에 유지할 수는 없습니다. 그들은 실제로 새로운 사람들이 충분히 똑똑하지 않다고 생각합니다 ...

그래서 예, 지금부터 회사가 버그 수정을 해외 사무소에 아웃소싱한다고 말하면 나를 믿습니다.

이것이 종이 봉지 관리 방법입니다.

철도에 서서 기차가 올 때까지 기다리십시오. 보면 머리 위로 종이 봉지를 넣고 POOF .. 기차가 사라졌습니다 !!. 마술!


9

회사가 다른 사람에게 내 엉망을 정리하도록 지불하는 것은 '깨끗한'코드를 가져 와서 새로운 기능을 추가 할 것으로 예상되는 경우를 제외하고는 좋은 생각처럼 들립니다. 그들이 너무 망쳐 서 고칠 수 없다면 디버깅을 디버깅하게 될 것입니다.

추가 개발자를 고용해야하므로 적절히 보상받지 않는 것이 바람직하지 않습니다.

다른 개발자가 스스로 고칠 수 있었을 때 교육하는 데 상당한 시간을 소비하는 것은 비생산적입니다.

저의 일부는 문제를 만드는 사람들이 문제를 해결하는 사람들이거나, 처음부터 버그를 만드는 것을 피할 동기가없는 것처럼 느낍니다.


6

개발자가 실수로부터 배우는 데 관심이 없습니까? 특정 도메인 지식없이 버그를 수정할 수 있습니까? 아웃소싱 파트너에게이 지식이 있습니까? 고정 부분은 시간이 가장 많이 걸리는 분석 부분입니다. 내 관점에서 볼 때 그것은 멍청한 결정입니다.


6

장래의 고용주가 "개발자가 버그 수정을 싫어하기 때문에 버그 수정을 아웃소싱했다"고 말하면 어떻게 생각하십니까? 당신의 관심사는 무엇입니까?

나는 멀리, 멀리, 멀리 도망 갈 것이다. 개발자는 항상 자신의 버그를 수정해야 할 책임이 있습니다. 개밥을 먹는 것은 좋은 공학의 기본 교리입니다.

또한 버그 수정은 개발보다 중요합니다. 개발은 코드 작성, 테스트 및 디버깅 / 수정입니다.

내가이 회사에서 얻는 것은 버그 수정을 2 차 과제로 취급한다는 것입니다. 그것은 그 자체로 꽤 혼란스럽고 나는 그들의 작업 품질 (그리고 ergo, 그들의 작업 환경)에 대해 크게 의문을 가질 것입니다. 더 혼란 스럽습니다. 그들의 공학 과정에는 분명히 사회 계층화가 존재한다.

결함은 항상 변경으로 인해 발생하며 일반적으로 버그는 변경을 도입 한 사람의 책임입니다. 버그의 본질과 그 해결 방법을 이해하는 것이 누가 창업자보다 낫습니까?

전 세계에 위임 된 경우, 원저자를 해외 엔지니어가 사용할 수 있도록하려면 어떻게해야합니까?

그는 버그와 마감일에 대한 백로 그만 가지고 있지만 Metropole의 지원을받지 않는 역외 엔지니어를 떠날 수 있을까요? 어떤 유형의 버그 수정이 가능합니까? 누가 그의 버그를 수정 했습니까? 그리고 메트로 폴 개발자들이 사후 버그 수정을 통해 학습하는 것을 방해하는 것은 무엇입니까?

모든 분야에 병신이 있습니다. 이것은 소프트웨어에서 특히 그렇습니다. 그것은 불가피하기 때문에, 유일한 선택은 당신보다 더 잘 알고 있거나 일을 올바르게하는 병신 들을 다루는 것입니다. 이 회사는 그 설명에 맞지 않는 것 같습니다.

한마디로 도망 치십시오.


2
"또한, 버그 수정은 개발보다 훨씬 중요합니다." 나는 당신이 거기에서 무엇을 의미하는지 알고 있지만, 말할 것입니다 : 나는 그러한 이분법을 추측 할 수 없습니다. 버그 수정은 본질적인 개발 측면입니다.
Dan Ray

1
@ Dan-네, 당신의 진술은 훨씬 정확합니다. 이러한 이분법은 존재하지 않습니다.
luis.espinal

4

그들은 많은 해외 ​​주니어 개발자들이 많은 수석 개발자 코드를 고칠 수있을 것으로 기대합니까? 간호사가 신경과 전문의의 모든 작업을 재확인하고 미케 크를 한 부분을 다시 실행하는 것과 같습니다. 나쁜 생각!


3

직원들이 실제로 개발중인 코드를 얼마나 잘 알고 있는지 걱정할 것입니다.
또한 추가 비용을 정당화하기에 충분한 버그가있는 이유가 궁금합니다. 또한 회사의 장기적인 미래에 대해 걱정할 것입니다. 웹에는이 회사를 주장하는 많은 기사가 있으며 동일한 산업에서도 여러 프로젝트에 동일한 코드를 사용합니다.

고장난 코드를 수정하는 것은 코드를 작성하는 과정의 일부이므로 6 개월 전에 잘못한 것을 더 잘 이해할 수 있으므로 다른 개발자가 실수를 해결하면 같은 실수를 저 지르지 않습니다. 반복해서 발생하는 버그?


3

이것은 "전망 고용주"비트를 제외하고는 나의 이전 고용주와 모호하게 들립니다. 법률 및 규정 변경에 필요한 새로운 기능을 추가하는 동시에 개발자는 기존 제품을 지원하기 위해 개발자를 잃고 너무 많이 잃었습니다 (사무실 수익의 60 %는 VB6 기반 제품에서 발생하며 MS는 VB6 런타임을 언급했습니다) 향후 운영 체제에는 배포되지 않으므로 Vista가 나왔을 때와 비슷합니다. 회사를 곧 공개 할 수있는 힘은 대차 대조표를 개선하는 데 필요한 자원을 모두에게 굶주리고 있습니다. 따라서 해외에서 채용하는 것이 시장에 머무를 수있는 유일한 방법입니다.

내 경험에 따르면, 견적은 당신의 예상 고용주가 싸다는 것입니다.


최악의 직업을 가지고 +1. 그들이 그 수입을 프로젝트에 충분히 사용하지 않은 것 같습니다.
Ramhound

"예상 고용주"비트를 제외하고 <LOL
Greg B

"이전 고용주"라는 문구가 있습니다. 축하합니다.
David Thornley

@Ramhound, David, Greg, 내가 시작했을 때 더 좋은 곳이었습니다. 12 월 말에 (5 주년이 지난 직후) 그 자리를 떠났습니다. 내가 고용 된 이후로 아무도 고용되지 않았으며 지난 2 년 동안 6 명의 개발자가 종료했습니다. 가장 최근에 출발 한 곳은 11 년입니다.
Tangurena

3

"버그 수정"의 의미에 따라 다릅니다. 이것이 개발 / 테스트주기 동안 버그를 수정하는 경우에는 매우 이상합니다. 이는 최초 개발자의 작업입니다. 반면에, 출시 된 제품의 유지 관리를 아웃소싱했음을 의미하는 경우 이는 예외가 아니며 걱정할 사항이 아닙니다.


좋은 점은 아무도 그 각도를 상상하지 못했습니다.
Greg B

@ 그레그 & 스티브-솔직히 중요하다고 생각하지 않습니다. 그들이 릴리스 버전에서 버그를 수정하고 있다면 개발자가 버그를 직접 작성하지 않으면 어떻게 수정 프로그램을 테스트 빌드에 병합 할 수 있을까요?
Ramhound

버그 수정이 소스 제어로 체크인 된 경우 다른 팀에서 다른 지점으로 쉽게 통합 할 수 있습니다. 전혀 중요하지 않습니다.
Steve

응용 프로그램이 더 이상 적극적으로 개발되지 않지만 어떤 이유로 기능을 유지 해야하는 레거시 시스템 인 경우에만이 시나리오를 실제로 승인하지만 좋은 지적을합니다. 문제가되는 것을 완전히 재 작성한 새로운 세대를 말하십시오.
Newtopian

2

내 경험에 따르면 외부 팀을 인수 한 후에는 버그를 수정하는 것만 큼 많은 시간이 소요될 수 있습니다. 속도를 높이고 개발 프로세스를 시작해야합니다. 그리고 지속적으로 속도를 유지했습니다. 조정은 코드를 작성하는 것보다 어렵습니다.


1

코드베이스에서 작업 할 경우 커밋 권한을 가진 모든 사람이 합리적으로 유능하다는 확신을 갖고 싶습니다. 인도에는 꽤 많은 사람들이 포함되지만 일반적으로 해외에있는 사람들은 포함되지 않습니다.

또한 대부분의 버그는 더 복잡한 코드 섹션에 있으며, 버그 수정을 적용하기 전에 해외 프로그래머가 이해하기 어려운 버그입니다.


1

이 정책은 실제로 일부 회사에서 무의식적으로 존재합니다. 나는 아웃소싱을 위해 일합니다. 저와 제 동료들은 현장 직원들보다 더 유능한 프로그래머입니다. 그들은 우리에게 도구 등을 사용하는 방법을 가르쳐달라고 요청하지만 그 반대편에서는 코드보다 더 빨리 문제를 발견 할 것입니다.

일반적으로 클라이언트의 프로그래머는 적어도 일부 사용자와 동일한 건물에 물리적으로 위치하므로 반구에 도달하지 못하는 컨텍스트를 얻을 가능성이 높습니다. 우리는 그것이 잘 작동한다는 것을 알았습니다. 나에게 누락 된 부분은 코드를 검토하지 않기 때문에 계약이 완료되면 우리의 어리석은 관행 때문이 아니라 일반적인 문제만으로 인해 놀라움이나 질문이있을 수 있습니다. 다른 사람의 프로젝트를 인수합니다.

어쨌든 우리의 경우 공식 정책이 아니기 때문에 기쁘다. 따라서 현장 프로그래머가 BA보다 조금 더 많은 것을 침식하게 될 것이라고 생각한다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.