다른 팀원 코드를 다시 작성하지 않은 규칙

우리는 집단 코드 소유권을 실천하고 있습니다. 이것은 모든 개발자가 코드를 변경하여 기능을 추가하거나, 리팩터링, 버그를 수정하거나, 디자인을 개선 할 수 있다는 것을 이해합니다.

그러나 여전히 팀에있는 개발자의 코드를 완전히 다시 작성하는 것은 어떻습니까? 먼저 물어봐야합니까? 모범 사례는 무엇입니까?

좋은 의사 소통이 항상 최선의 방법이라고 생각합니다. 개발자에게 문의하여 코드가 코딩 된 이유가 있는지 확인하십시오. 그것은 그들이 오랫동안 그것을 되 찾아서 리팩토링하는 것을 의미했을 수도 있고, 아주 좋은 이유로 그렇게했을 수도 있고, 또는 둘 다 대화에서 무언가를 배울 수있을 수도 있습니다.

사전 의사 소통없이 입장하고 재 작성하는 것은 나쁜 의지입니다.

이 질문의 전제는 기존 답변이 적절하게 해결하려고 생각하지 않는다는 많은 우려를 제기합니다. 여기에 몇 가지 후속 질문을하겠습니다.

1. 리팩토링이 아닌 재 작성에 대해 이야기하고 있다고 확신합니까? 외부 동작을 변경하지 않고도 개선 된 (또는 단순히 다른) 구현 결과가 팩터이라고 정의함으로써, 스타일 또는 코드 구조에 변화 하지 재기록. 모 놀리 식 500 라인 루틴을 50 개의 서브 루틴 세트로 나누려면 약간의 새로운 코드를 작성해야하지만 재 작성은 아닙니다. 다시 쓰기 라는 용어 는 전체 제품 또는 기능을 폐기하고 처음부터 다시 시작 함을 의미합니다. 가볍게 가져갈 것이 아닙니다.

2. 원래 코드의 동작이 잘못되었거나 구현이 본격적인 재 작성이 필요한 버그 인 경우 왜 팀 프로세스에 의해 포착되지 않고 적절한 맥락에서 (즉 사회적으로가 아니라) 해결 되었습니까? 테스트, 코드 검토, 디자인 검토 등을 통해 건강하지 않은 팀에 나쁜 코드 나 의심스러운 코드를 신속하게 노출시켜야합니다. 이러한 코드가 있습니까?

3. 관리자 / 기술 담당자가 문제를 알고 있습니까? 그렇지 않은 경우 왜 그렇지 않습니까? 어떤 종류의 프로세스를 사용하든 코드 품질은 일반적으로 개발 관리자의 책임입니다. 그 또는 그녀는 당신이 물어봐야 할 첫 번째 사람입니다. "그래서 그렇게 엉뚱한 코드를 작성했습니다" 라는 맥락에서가 아니라 단순히 "여기서 중요한 문제가 있다고 생각합니다. 다시 쓰기에 대해 이야기 할 수 있습니까?" 이 유형의 토론을 보증하지 않으면 다시 쓰기를 보증하지 않습니까?

4. 문제가되는 코드의 크기와 범위가 재 작성에 대한 진지한 논의를 보장 할만큼 충분히 큰 경우 왜 한 명의 개발자가 독점적으로 소유하고 있습니까? 코드를 보았고 "다시 쓰기"를 생각한 모든 시간이 아닐지라도 대부분 12 명이 다른 사람들에 의해 짓밟 히게되었으며 나쁜 점은 스타일 불일치, 잘못되거나 변경된 가정 및 오래된 것이 축적 된 직접적인 결과입니다. 구식 해킹. 코드는 공유 소유권으로 인해 시간이 지남에 따라 가시가 커 집니다.

   필자의 요점은, 한 사람이 집단 소유권을 수행하는 환경에서 그렇게 큰 코드를 소유한다는 것은 이상하다. 다른 사람들이이 개발자의 코드를 다루는 것을 두려워합니까? 그들은 주제를 제기하는 것을 두려워합니까? 어쩌면 그룹 역 동성 또는이 개발자에게 근본적인 문제가있을 수 있습니다. 있다면 무시하지 마십시오. 또는, 양자 택일로, 아마도 그 것이다 당신의 처음이 프로젝트에 참여, 그렇다면, 왜 당신이 이렇게 일찍 게임의 재 작성에 대해 생각? 상황에 대해 뭔가가 나를 보완하지 않는 것 같습니다.

5. 질문은 첫 번째 단락에서 any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs. 재 작성은 것 없는 이 일을? 아니면 여분의 일을 할 것입니까? 그렇다면 무엇입니까? 근본적으로, 다시 쓰기를 원하는 이유 는 무엇 이며 제품이나 팀에 도움이 될 것이라고 확신하십니까? 나에게 대답 할 필요는 없지만, 팀과 논의 할 때 그리고 언제 논의 할 것인지에 대한 몇 가지 객관적인 요점을 갖는 것이 좋습니다.

나는이 질문이 많은 맥락을 수반한다고 생각 하며 그 맥락에 대한 명확한 이해 없이는 대답 해서는 안된다 . "정답"은 전적으로 팀, 제품, 조직, 성격, 프로세스, 원본 코드의 범위, 변경 범위 등에 따라 달라집니다. 이것은 온라인 Q & A 사이트가 아닌 팀 을 따라야 할 문제인 IMO 입니다.

왜 코드를 편집하고 있습니까?

버그가 있습니까 아니면 더 근본적인 디자인 결함입니까?

전자의 경우 코드의 사소한 버그 일 수있는 문제를 해결하기 위해 다시 작성하는 것에 대해 걱정할 것입니다.

후자의 경우, "나의"코드가 잠재적으로 다시 작성 될 것이라는 기대가 있지만, 그 코드에 대해 완전히 기뻐할 것입니다.

그것이 공동 코드 소유권의 요점입니다. 여러분이 작성하는 코드는 더 좋은 것이 나오면 수정되거나 심지어 교체되어야합니다.

일반적으로 코드에 대한 책임이 귀하에게 있음에 동의하면 개선 된 코드가 있으면 다시 작성해도됩니다. 다른 개발자와 우선적으로 의논하십시오. 특정 방식으로 작성된 유효한 이유가있을 수 있습니다. 개인적인 차원에서 많은 개발자들이 자신이 생산하는 것에 정서적으로 투자하고 다른 사람들이 말했듯이, 당신은 악의를 원하지 않습니다.

특히 팀 역학에 따라 다릅니다. 주니어 개발자 코드를 다시 작성하려는 선임 개발자는 코드 를 다시 작성하기 전에 코드 검토 (내 사이트)를 수행해야 합니다. 그렇게하면 주니어 개발자가 상황에서 배울 수 있습니다.

원래 개발자가 팀에 있는지 여부, 또는 원래 개발자인지 여부는 중요하지 않습니다. 의 완전한 재 작성 어떤 공유 코드는 다음과 같은 이유로, 당신의 팀에 의해 실행해야합니다 :

• 상당한 시간이 걸립니다. 다른 사람이 관련 변경 작업을하고 있다면 시간을 낭비하고 싶지 않습니다.
• 다른 사람들은 다른 관점을 가지고 있습니다. 20 년 동안 프로그래밍을 해왔더라도 다른 사람이 거의 만지지 않는 코드와의 상호 작용에 대해 알 수 있습니다.
• 다른 개발자는 소스 코드의 "고객"입니다. 소스 코드는 다른 개발자가 읽을 수 있도록 작성되었습니다. 아키텍처 요구 사항, 스타일 입력 또는 해당 코드에서 원하는 기능 요청이있을 수 있지만 시간이 없었습니다. 다른 개발자가 다른 방식으로 리팩토링해야하는 개발자를 찾기 위해 리팩토링을 마치고 싶지는 않습니다.

Matthew Flynn이 말했듯이 먼저 개발자와 대화해야합니다. 초기 개발자는 기능에 대한 중요한 정보를 제공하고이 솔루션 또는 해당 솔루션이 제공된 이유를 설명 할 수 있습니다.

그러나 코드를 리팩토링하거나 다시 작성하기 전에 해당 코드가 포함 된 백업 또는 분기를 작성하십시오. 이전 코드가 제대로 작동하면 복구 될 가능성이 있습니다.

소스 제어 시스템 (내가 가지고 있다고 가정)이 있다면 가능하면 전체 코드를 리팩토링하고 나중에 제대로 작동하는지 확인한 다음 체크인하십시오.

적어도 새 코드가 제대로 작동하는지 확인하기 전에 이전 코드를 삭제하지 마십시오. 그러나 오래된 코드를 영원히 남겨 두는 것도 좋지 않습니다. 테스트를 통과한지 한 달 후와 같이 언젠가 코드를 삭제하는 것이 좋습니다.

그것의 범위는 무엇입니까?

• 좀 더 효율적으로 작업하기 위해 몇 줄을 재 작업하고 있다면 그렇게하십시오. 미묘한 행동을 지울 위험이 있는지 물어보십시오. 스크럼 동안 또는 전자 메일을 통해 변경 사항을보고하십시오 (실제로 오타가 아닌 경우).

• 적당한 크기의 수업을 재 작업하는 경우 디자인 / 동작을 이해하도록 요청해야합니다. 같은 지역에서 일하는 사람이 나를 알고 협조 할 수 있도록 사람들에게 미리 알려주십시오.

• 더 큰 시스템을 재 작업하는 경우 팀과 협력하여 변경 사항을 인식하고 설계를 계획해야합니다.

원래 작가가 있다면 그들과 대화하십시오. 단지 에티켓이 아니라 추가 정보를 위해, 모르는 경우 나 상황이있는 경우. 때때로, 그들은 당신에게 가치있는 것을 말할 것입니다.

우리는 심오한 코드 컨트롤을 가지고 있습니다. 현재 검토 및 유지 관리가 필요한 많은 것들이 있으며 코드 검토를 할 사람도 없습니다. 이전의 작가들 (moi를 제외하고)은 어떤 코드도 언급하지 않았다. 그리고 그들은 회사에서 나왔습니다. 코드에 대해 물어볼 사람이 없습니다.

다시 쓰면 날짜와 이름 / 이니셜은 물론 주석 처리 된 주석과 주석 처리 된 이유와 함께 주석 처리됩니다. 나는 이름이나 이니셜, 날짜, 이유가 추가 된 새로운 코드에 대해 언급합니다.

어떤 기능 / procs / SQL / etc 등을 나타내는 추가 주석이 패키지 헤드 (일반적으로)에 작성됩니다. 날짜와 함께 변경되었습니다. 변경된 섹션을 쉽게 찾을 수 있으며 해당 섹션에는 전체 문서가 있습니다.

댓글이 싸다. 날짜는 변경된 사항을 나타내는 지표이며 x- 수 (일 / 수정 / 신규 고용 / 퇴직) 후 코드는 이전 주석을 정리하고 나머지는 새로운 기준선입니다.

내 관찰에서 일반적인 관행은 다음과 같습니다. 코드를 삭제하지 마십시오. 의견을 남기고 보관하십시오.

내 연습은 그것을 교체하는 동안 주석 처리하는 것입니다. (주로 참조 용) 작업 변경의 최종 커밋에서 삭제하십시오. 버전 관리 및 변경 사항을 되 돌리는 방법에 대한 이해가 필요합니다.

오래된 주석이 달린 코드를 찾으면 적절한 주석이있는 별도 커밋에서 코드를 삭제하려고합니다. 따라서 필요한 경우 변경 사항을 되돌 리거나 쉽게 점검 할 수 있습니다.

모든 변경 사항에 대해 개정 내역을 사용하여 코드를 만든 개발자를 결정할 수 있어야합니다. (주석이있는 개정 내역이 여기에 도움이됩니다.) 가능하면 코드를 확인하십시오. 많은 프로젝트에서 정리 시간이 발생하지 않고 문제가 남아 있습니다. 필요한 정리 기록이 있는지 버그 추적기를 확인하십시오. 때때로 변경 사항은 릴리스를 정리해야합니다.

코드를 변경하는 경우 해당 코드를 사용하는 이유가 있습니다. 코드가 왜 같은지 알아 보려면 원래 개발자에게 문의하십시오. 수정하지 않는 정당한 사유가있는 경우 수정되지 않은 이유 또는 변경하지 않아야하는 이유를 설명하는 설명을 추가하십시오. 이렇게하면 다음 개발자가 시간을 절약 할 수 있습니다.

FixMe, ToDo, Bug 및 Hack과 같은 태그를 사용하여 나중에 변경 될 수있는 코드를 표시 할 수 있습니다. (제한 사항을 버그로 태그 지정하고 필요한 조건에서 트리거되지 않으면 수정하지 않아도됩니다.) 가정 회계 프로그램이 2 천만 달러로 오버플로되면 버그가 될 수 있지만 많은 시간을 낭비하지는 않습니다. 그것.

코드를 수정하는 것이 적절한 경우 원래 개발자가 코드 검토 변경을 수행해야합니다.

재 작성이 필요한 이유에 따라 달라질 수 있습니다. 작성된 내용에 문제가 있고 항상 문제가 있었기 때문에 앞으로 코드를 수정 해야하는 빈도를 최소화하기 위해 그것에 대해 이야기해야합니다.

이 경우 코드를 수정할 때 페어링하는 것이 좋습니다. 이런 식으로, 그것은 중간 상태의 좋은 예를 제공하며 , 재 작성된 코드가 더 나은 이유에 대한 컨텍스트를 제공 합니다. 또한 (개인 운동으로 만 사용하는 경우) 완전히 다시 작성하지 않고 코드를 더 잘 리팩토링 해보십시오. 더 어려울 것이지만, 그것은 당신에게 좋습니다.

반면에 다시 쓰기가 필요한 경우가 있습니다.

• 팀은 코드가 작성된 이후 많은 것을 배웠으며 코드를 작성한 개발자는 입력하지 않아도 코드를 다르게 작성할 것입니다.

• 새로운 기능 요구 사항은 대상 미니 재 작성이 적합하도록 상황을 변경합니다.

이 경우에는 아마도 대화를 방해하지 않을 것입니다.

그것에 대해 생각 하면 코드가 오래있을수록 대화가 덜 필요할 것 같습니다.

@aaronaught가 좋은 지적을했다고 생각합니다. 이것은 내가주고 싶은 대답으로 이어집니다. 즉 누가 누가 변경을했는지 (그리고 왜) 누가 코드를 작성했는지에 달려 있습니다.

내 개인적인 경험에서 코드는 의도 한대로 작동하지 않거나 실제로 수행하는 작업을 확장해야하기 때문에 일반적으로 변경됩니다.

Team dev 환경에서는 원본 코더와 대화 할 필요가 없으며, 코드에서 명확하지 않아야합니다.

그러면 대부분의 시간을 소비하는 질문이 생겨납니다. 이것은 원래 프로그래머가 의도 한 것입니다. 그리고 가장 자주 코드가 삭제되도록하는 질문이며, 우리가 모든 것을 주석 해야하는 이유와 경험이없는 주니어 프로그래머가 가장 많이 찾는 이유입니다 종종 파울입니다.

다른 사람의 코드를 변경하는 프로그래머 (리팩토링)는 실제로 예의 바르게 문제를 해결하기 위해 이미 사용중인 코드와 동일한 코딩 스타일을 복사해야합니다. 먼저 원래 코드의 작동 방식과 시도 대상을 파악하기위한 단계를 수행하십시오 실제로 달성하려고합니다. 종종 이것은 그 자체로 버그를 식별하지만 확실히 다음 사람들이 귀하의 코드를 볼 때 고통을 견뎌야합니다.

우리 팀에서는 누구나 어떤 것도 삭제, 리팩터링 또는 재 작성할 수 있으며, '소유권'은 게으름을 유발하는 관행으로 간주합니다. 한 사람이 변경 사항을 통보받는 것처럼 코드를 읽을 수있게 만들어야하는 이유는 무엇입니까?

간단히 말해, 아니요, 코드의 원래 작성자에게 요청할 필요가 없으며 코드를 볼 때 코드를 읽을 수 없거나 개선해야한다는 신호입니다. 너의 기술들. 그러나 다시 작성 할 때 실수로 필요한 기능을 제거하지 않았다는 것을 확신 할 때까지 원래 코드를 그대로두고 주석 처리 한 것이 좋습니다. 누구도 완벽하지 않다.

종종 코드는 특정 이유로 특정 방식으로 작성됩니다. 저자에게 변경 내용을 전달하면 항상 최선을 다합니다.