동료가 최근 회사를 떠났습니다. 떠나기 전에, 메모리 누수가 심한 구성 요소를 코딩하여 생산 중단을 일으켰습니다 ( OutOfMemoryErrorJava). 문제는 본질적으로 HashMap증가하고 항목을 제거하지 않은 문제였으며 솔루션은 HashMap캐시 구현 으로 대체했습니다 .

전문적인 관점에서 볼 때, 나는 그가 그 오류로부터 배울 수 있도록 결함에 대해 알려 주어야한다고 생각합니다. 반면에 사람들이 회사를 떠난 후에는 종종 더 크고 더 나은 것을 위해 남겨둔 레거시 프로젝트에 대해 듣고 싶지 않습니다.

이런 상황에 대한 일반적인 프로토콜은 무엇입니까?

당신은 그가 실수했다고 그에게 전직 동료를 사냥하지 않습니다. 친구에게 실수했다고 말할 수 있습니다.

그가 친구인지 전 동료인지는 당신에게 달려 있습니다.

아무것도하지 마세요.

1. 누군가에게 연락을 취해 망쳐 놓았다고 말했지만 우리는 그것을 고쳤습니다. 비전문가이며 아무리 노력해도 긍정적으로 받아들이지 않을 것입니다.
2. 직원이 아닌 사람에게 제공하는 코드에 대해 대화가 원격으로 유용 할 정도로 깊이있는 대화는 잠재적 인 NDA 문제와 상관없이 나쁩니다.

NDA를 받고 있다면 전직 직원이든 아니든 IP 관련 문제에 대해 회사 외부의 사람과 이야기하는 것은 결코 큰 일이 아닙니다.

NDA가 아닌 사람은 신경 쓰지 않을 것이라고 말하고 싶습니다.

그 옆으로, 그 사람은 불만을 품었습니까? 실제로 의도적 인 것이 었습니까?

동료를 괴롭 히면 간단하고 확률이 높다는 실수로 그들은 며칠 후에 문제를 깨달았을 것입니다. 나는 일을 마치고 집에 돌아와서 ".. 휴식, 알고리즘에 결함이 있음을 깨달았다. 내일 다시 풀어야한다"는 것을 깨달았다.

이 동료는 퇴근 후에도 계속 연락을주고받는 친구입니까? 그렇다면, 바에서 맥주를 ​​마시는 경우 / 언제나 이에 대해 이야기하십시오.

그렇지 않으면 왜 귀찮게합니까?

추신. NDA에 관한 비밀은 무엇입니까? Mr X는 어쨌든 코드를 작성한 사람이며, 최근에 떠날 경우 소프트웨어는 동일한 수준의 공개를 계속합니다.

이 대화가 떠나고 3 년 후에 일어난다면 상황이 다를 수 있습니다.

이 사람이 어떻게 떠 났는지와 당신과의 관계에 달려 있습니다.

또한, 무슨 상관이야? 나는 당신이 그를 "오류에서 배우도록"도와 주길 원한다는 것을 알지만 당신은 정말로입니까? 그에게 로그 *와 스택 추적 *을 보여 주겠습니까? 문제를 진단하기 위해 수행 한 단계를 보여 주겠습니까? 문제의 위치를 ​​알 수 있도록 그에게 출처 *를 보여 주겠습니까?

그렇지 않다면 아마도 그의 시간과 시간을 낭비하고있을 것입니다.

* 회사 자산 / 데이터를 비 직원에게 공개하는 데 어려움을 겪고 있습니까?

당신이 그에게 말하기로 결정했다면 당신은 그의 코드의 모든 검토 자에게도 말해야합니다! 그들은 똑같이 책임이 있습니다! 나에게 그것은 당신이이 남자를 타지 않고 그를 파고 싶어하는 것 같습니다. 가자, 그는 신경 쓰지 않을 것입니다.

아마 아닙니다

친구 든 동료 든 나에게 무의미 해 보입니다. 그리고 어떤 상황에서는 그들과 당신, 그리고 당신과의 관계에 해로울 수 있습니다.

우리 모두는 때때로 실수를합니다.

사실, 내가 동료들에게 말하고 싶은 유일한 요소는 이것입니다. 이것은 그들이 일반적으로하지 않을 것이라는 것을 아는 실수입니까 / 그들이 어떻게 처리해야하는지 알고있는 상황입니까?

대답이 '예'라면 교육적 가치 가 없기 때문에 버그를 제기 할 필요 가 없으므로 정보를 제공 할 의무가 없습니다. 당신이 그들의 마지막 날에 술이 한 일이나 계획 그들에 걸쳐 실행하고 동료와 동료 전문가로 그들과 함께 좋은 교감이있는 경우, 물론, 당신은 할 수 무엇보다도 우호적 인 또는 무해한 농담을 공급하기 위해, 그것을 언급.

대답이 '아니요'인 경우, 그 오류를 이해하고 도움을 줄 의무가있을 수 있습니다 ( '전문적'이라고 할 수는 없습니다).

그것을 시민으로 유지

대부분의 사람들은 일반적으로 자신의 직업에 대한 비판을 좋아하지 않으며, 개발자 / 프로그래머는 그다지 적지 않으며, 떠나는 프로그래머는 아마도 더 낮은 관용을 가질 것입니다. 왜 귀찮게하고 나쁜 메모를 남긴다는 인상을 줄 위험이 있습니까?

물론, 직원이 불충분 한 직원이라면 적용되지 않지만, 숙련 된 동료 프로그래머라면 다른 사람이 실수를 강조 할 수있는 이유를 알 수 없습니다. 둘 다 웃을 수 있습니다. 다시 말하지만, 그들이 많은 것을 배우지 않을 것이라고 생각하고 그 뒤에 남은 것을 잊어 버립니다.

적법한?

다른 접근 각도에서, 그들이 회사를 떠난 경우, 그것은 실제로 계약과 회사의 보안 정책에 달려 있습니다. 이전 동료에게 코드 (또는 그 문제에 대한 기타 사항)를 가져 가서는 안됩니다.

긍정적 인 생각

마지막으로, 이전 동료에게 연락하여 남은 코드베이스에 대해 논의한 유일한 상황은 다음과 같습니다.

• 코드의 특정 영역을 조사하는 동안 그늘에 대한 확인 요청
• 내가 특별히 숙달 한 것으로 밝혀진 코드에 대해 축하하기 위해, 그것이 없으면 내 인생을 더 나쁘게 만들었을 것이다.
• 그들이 출시되기 전에 떠났을 때 성공적인 출시에 대한 희소식을 공유하기 위해 (또는 그들이 작업했던 제품과 관련된 유사한 큰 발표).

그들의 실수에서 배운다

당신이 확실히 할 수있는 일은 나머지 팀원들에게 오류가 다시 발생하지 않도록 나머지 팀원들에게 오류를 지적하는 것입니다. SCM 또는 저자의 실제 오류를 가리킬 필요가 없습니다. 그것은 비난 게임이 아닙니다.

그것은 문제의 범위를 벗어 났지만 여전히 오류를 수정하고 그 기원, 영향 및 해결을 문서화하고 가능한 경우 다시 표시되지 않도록 테스트를 구현해야한다고 지적합니다.

누군가에게 말하는 것은 합법적이지 않을 수 있습니다. 코드가 오픈 소스가 아니라면 잠자는 개들이 거짓말을하도록하십시오.