코드 소유권이 코드 냄새입니까?

논쟁의 여지가있는 프로그래밍 의견 스레드 에서이 답변을 읽은 이후로 내가 생각한 것입니다 .

당신의 직업은 자신을 일에서 벗어나게하는 것입니다.

고용주를위한 소프트웨어를 작성할 때 사용자가 작성하는 소프트웨어는 모든 개발자가 선택할 수 있고 최소한의 노력으로 이해할 수있는 방식으로 작성되어야합니다. 잘 디자인되고, 명확하고 일관되게 작성되고, 깔끔하게 형식화되고, 필요한 곳에 문서화되고, 예상대로 매일 빌드되고, 저장소에 체크인되고, 적절하게 버전이 지정됩니다.

당신이 얻을 경우 버스에 치 , 해고, 해고, 또는 작업을 걸어, 당신의 고용주는 순간의 통지에 당신을 대체 할 수 있어야하고, 다음 사람은, 자신의 역할에 단계 코드를 선택하고 위로하고 수 일주일 내내 달리기. 그가 그렇게 할 수 없다면, 당신은 비참하게 실패한 것입니다.

흥미롭게도, 저는 그 목표를 갖는 것이 저의 고용주들에게 더 가치있는 것으로 나타났습니다. 일회용을 위해 노력할수록 나는 그들에게 더 가치있게됩니다.

그리고 이것은 이것 과 같은 다른 질문에서 조금 논의 되었지만, 더 빈칸에서 논의하기 위해 다시 제기하고 싶었습니다 . " 코드 냄새입니다! "관점-실제로 다루지 않았습니다. 아직 깊이.

저는 10 년 동안 전문 개발자였습니다. 괜찮은 수준의 새로운 개발자가 비교적 신속하게 선택할 수있을 정도로 코드가 잘 작성된 작업이 있었지만 대부분의 경우 업계에서는 매우 높은 수준의 소유권 (개인 및 팀 소유권)이 표준. 대부분의 코드 기반에는 문서, 프로세스 및 "개방성"이 없어서 새 개발자가 코드를 선택하여 신속하게 작업 할 수 있습니다. 코드 기반을 잘 아는 사람 ( "소유자")만이 알 수있는 수많은 미묘한 작은 요령과 해킹이 항상있는 것 같습니다.

물론, 이것에 대한 명백한 문제는 : 만약 사람이 그만두거나 "버스에 부딪히면"어떻게 될까요? 또는 팀 차원에서 : 팀 전체가 팀 점심 시간에 외식 할 때 식중독에 걸리고 모두 죽으면 어떻게됩니까? 팀을 비교적 무작위로 새로운 무작위 개발자로 교체 할 수 있습니까? -과거의 여러 직업에서 그런 일이 전혀 일어나지 않는다고 생각합니다. 이 시스템에는 트릭과 해킹이 가득하여 " 알기 만하면됩니다 ". 신입 사원은 수익성있는 비즈니스주기 (예 : 새로운 안정적인 릴리스)보다 훨씬 오래 걸리므로 문제가 다시 발생합니다. 요컨대, 제품을 버려야 할지라도 놀라지 않을 것입니다.

분명히 한 번에 전체 팀을 잃는 것은 매우 드 would니다. 그러나 나는이 모든 것에 더 미묘하고 불길한 것이 있다고 생각합니다.이 스레드를 시작하려고 생각한 시점입니다. 기본적으로 코드 소유권에 대한 높은 요구는 종종 기술 부채의 지표 라고 생각 합니다 . 시스템에 프로세스, 의사 소통, 디자인, 부족한 트릭 및 해킹이 부족하면 "알아야 할 것"등이 있습니다. 이는 일반적으로 시스템이 점진적으로 깊고 심도 깊은 기술적 부채에 빠지고 있음을 의미합니다.

그러나 문제는 코드 소유권이 종종 프로젝트와 회사에 일종의 "충성도"로 나타나고, 업무에 대한 "책임"의 긍정적 인 형태로 제시되기 때문에 그것을 완전히 비난하는 것은 인기가 없습니다. 그러나 동시에 방정식의 기술적 부채 측면은 종종 코드베이스가 점차 개방적이지 않고 작업하기가 더 어렵다는 것을 의미합니다. 특히 사람들이 이동하고 새로운 개발자가 대신해야 할 때 기술 부채 (예 : 유지 관리) 비용이 급증하기 시작합니다.

어떤 의미에서, 나는 코드 소유권에 대한 높은 수준의 요구가 공개적으로 냄새가 나면 (일반적인 프로그래머 상상력) 우리 직업에 좋은 것이라고 생각합니다. 작업에서 "책임과 자부심을 얻는"것으로 여겨지는 대신, "기술적 부채를 통해 스스로를 보호하고 인공적인 일자리를 창출하는 것"으로 여겨 져야합니다.

그리고 나는 시험 (실험이 생각한 것)은 기본적으로 다음과 같아야한다고 생각합니다. 내일 사람 (또는 전체 팀)이 지구의 얼굴을 사라지게한다면 어떨까요? 프로젝트에 심각한 부상을 초래할 수 있습니까? 아니면 새로운 사람들을 데려 와서 사람들에게 문서를 읽고 파일을 도와주고 며칠 동안 코드를 가지고 놀아 줄 수 있을까요? 몇 주 안에 사업을하고 (한 달 정도면 전체 생산성으로 돌아 가기)?

코드 소유권간에 차이를 만들어야한다고 생각합니다.

• 책임의 관점에서
• 코드 스타일 / 해킹 등의 관점에서

첫 번째는 격려되어야합니다. 품질이 낮은 코드와 버그에 대해 책임이있는 사람이 없으면 나쁜 일이 발생 합니다. 그렇다고 자신의 코드와 관련된 버그를 항상 할당해야한다는 의미는 아닙니다. 코드가 올바르게 작성되면 누구나 코드의 어느 부분에서나 버그를 수정할 수 있습니다. 그러나 버그에 대한 피드백이 없으면 동일한 버그를 반복해서 생성합니다 .

코드 소유권은 관리자와 개발자, 특히 개발자 모두에게 많은 도움이 될 수 있습니다. 프로젝트에서 3 명의 개발자가 작업하는 동안 제품의 80 %가 내 코드에 있고 해당 버그의 75 %가 SQL 인젝션과 관련이 있다는 것을 알고 다음에 코드를 작성하는 데 더주의해야합니다. 데이터베이스 쿼리를 올바르게 작성하기 위해 추가로 노력하십시오.

두 번째 것 (코드 스타일 / 해킹 등의 코드 소유권)은 대부분 나쁜 것입니다. 그것은 제품에 무엇을 가져 옵니까? 제품의 품질을 높이지는 않지만 소스 코드의 균일 성을 떨어 뜨리고 최근에 유지하기가 어렵습니다 .

많은 대규모 프로젝트의 경우 사람들은 동일한 코드로 작업하면서 평생 머 무르지 않습니다. 그리고 여기에서는 버스에 치인 개발자와 같은 끔찍한 일에 대해서도 이야기하지 않습니다.이 경우 코드 소유권이 첫 번째 관심사라고 생각하지 않습니다. 그러나 많은 사소한 생각이 발생합니다. 사람들이 개발에서 관리 또는 다른 직업으로 이주하거나 다른 프로젝트를 선택하거나 다른 일을하거나 다른 언어를 사용하기 시작합니다 (프로젝트에 여러 언어가 사용되는 경우).

프로젝트의 코드 조각을 다른 프로젝트에서도 재사용 할 수 있으며,이 다른 프로젝트를 작업하는 개발자는 코드 작성자에게 조언을 구하지 않고 새로운 요구에 맞게 코드의 일부를 수정하려고합니다.

코드 냄새입니까? 글쎄, 그것은 코드 냄새가 무엇을 의미하는지에 달려 있습니다. 저에게는 프로젝트 의 전반적인 일관성과 올바른 관리에 관한 것 입니다. 좋은 프로젝트에서

• 나중에 코드를 더 쉽게 이해할 수 있도록 코드 스타일 지침이 시행됩니다.
• 숙련 된 개발자는 KISS 원칙을 위반하지 않으므로 나중에 경험이 적은 동료가 소스 코드를 이해하는 데 도움이됩니다.

결론적으로 코드 소유권은 버전 관리를 통해 추적해야하지만 코드 조각이 사용자 나 다른 사람이 팀에 의해 작성되었다고 말할 수는 없습니다 .

먼저 "코드 소유권"을 정의해야합니다.

코드의 일부 (부분)가 개발 초기 단계에있을 때 종종 다음과 같은 이유로 한두 사람을 "소유자"로 지정해야합니다.

• 처음에는 명확한 사양이나 요구 사항이 없으며 개발자는 스스로 정보를 수집해야합니다. 이러한 발견의 수집 및 문서화에는 시간 간격이 있습니다.
• 코드 조각이 활발하게 수정 될 때 충돌하는 편집을 피하십시오.
• "소유자"는 기능 개발 진행 상황을보고 할 수있는 사람입니다.

일반적으로 각 작업마다 하나의 소유자가 있습니다. 페어 프로그래밍으로 이중 소유자가 가능합니다. 좁게 지정된 "코드 소유권"이 없으면 그렇게하는 것이 실용적이지 않습니다.

참고 : 개발 중 다른 문제에 대해서는
@MainMa의 답변 을 참조하십시오 . 이러한 경우 "코드 소유권"은 더 큰 문제의 증상입니다. 즉, 최적의 아키텍처 선택, 코딩 스타일 불일치 및 일반적으로 코드 품질 부족입니다.

코드베이스에 조각을 쓰고 승인하면 ( "완료")보다 일반적인 "코드 소유권"질문이 나타납니다.

• 이 코드 조각 /이 기능 부분에 대한 모든 질문에 대답 할 수있는 전문가는 누구입니까?
• 이 지식이 요구 사항 문서, 단위 테스트, 승인 테스트, 변경 로그, 프로젝트 위키 등과 같은 유형의 인공물에서 포착 되었습니까?

서면 사양으로 공식화하기 어려운 일부 도메인 지식 (고객 요구 사항에 대한 암묵적 이해, 비전 시스템과의 호환성 문제 등)이 항상 있습니다. 따라서 재난 발생시 도메인 지식이 일부 손실 될 수 있습니다.

도메인 지식의 상실과 함께 시스템의 세부 사항을 설명 할 수있는 전문가 답변을 잃게됩니다. 이런 측면에서 전문가의 상실은 보편적으로 나쁜 것입니다. 지식은 이전에 포착되었습니다.

이것은 "전문가"의 존재가 나쁘다는 것을 의미하지는 않습니다. 전문가가 서면 지식의 "캐시"라고 생각하십시오. 전문가들은 종종 서면 지식을 찾고 소화하는 것보다 더 빨리 질문에 대답 할 수 있습니다.

그러나 때때로 "코드 소유권"은 외부 사용자가 코드를 수정하지 못하도록 프로젝트의 활성 개발자가 설정 한 장벽을 말합니다.

• 누가이 코드를 변경할 수 있습니까?
  • 명백한 버그를 수정하려면?
  • 코드가 다른 요구 사항을 충족 시키려면?
  • 자신의 취향에 맞게 코드를 완전히 다시 작성하려면?

좋은 장벽과 나쁜 장벽이 있습니다 :

• 좋은 장벽
  • 도메인 지식-요구 사항과 아키텍처 / 코딩 스타일을 얼마나 잘 이해하고 있는지
  • 프로그래밍 및 디자인 기술-프로젝트의 디자인 및 코드 품질을 향상시키는 기술이 있습니까?
• 나쁜 장벽
  • 원래 개발자 팀에 있지 않았으므로 변경할 수 없습니다.
  • 버그 수정 만 환영합니다. 기능 향상은 환영하지 않습니다.

이 경우 다른 프로젝트의 소스 코드를 편집 할 수있는 권한은 코드 소유권을 기반으로하지 말아야하며 장점 기반이어야합니다.

마지막으로 @Graham Lee의 답변 은 부서 화로 인한 지식과 아키텍처의 단편화를 지적합니다.

이 경우 "코드 소유권"은 부서 화 증상 중 하나입니다. 두 번째 증상은 "다른 팀의 프로젝트에 대한 관심 부족"입니다. 조직의 관리자는 팀과 부서간에 지식 이전 및 협업을 장려하기위한 조치를 취해야합니다.

더 설득력있게 일부 회사 (한 곳에서 근무한)는 기능 팀을 중심으로 관리 구조를 구성합니다. Windows 클라이언트 개발자, 설치 관리자 팀, 백엔드 개발자 등을 관리합니다. 이것은 당신이 묘사하는 강력한 코드 소유권으로 이어질뿐만 아니라 비즈니스가 작동하는 방식으로 그것을 코드화합니다. 소프트웨어 아키텍처를 정치적 번화로 바꿉니다.

이것이 문제입니까? 아키텍처가 최적이 아닌 경우입니다. 예를 들어, 고객의 유스 케이스 인 경우 설치 프로그램이 더 잘 작동하거나 더 저렴하다고 말할 수는 없습니다. 팀과 관리자로부터 제어를 받기 때문입니다. 기능 모듈 사이의 구분은 엔지니어링 부서의 운영 방식에 대한 사실이되었으며 이러한 사실을 변경하려면 많은 격변이 필요합니다.

[BTW 위의 논의가 명확하지 않은 경우 귀하의 질문에 대한 답변은 예입니다. 코드 소유권은 코드 냄새가납니다. 좋은 아이디어를 가진 영리한 사람이나 코드 작업이 필요할 때 사용할 수있는 사람을 막을 수 있기 때문입니다. 명백하게 변덕스러운 변화를 막기위한 통제를하는 것이 좋은 일이지만, 버그를 수정하는 방법을 볼 수있는 엔지니어가 있고 버그를 해결할 시간이 있다면 다른 누군가가 버그가있는 코드를 작성했기 때문에 해당 엔지니어를 차단해서는 안됩니다. ]

약간 다른 관점에서 질문을 다루면 코드 소유권은 코드 냄새가 아닙니다. 대신 관리 및 자원 조달 냄새 입니다.

코드 냄새가 무엇을 의미하는지 생각해보십시오. 코드를 볼 때 코드 및 / 또는 소프트웨어 디자인에 옳지 않은 것을 알려주는 은유입니다.하지만 문제가 무엇인지 손가락을 넣을 수는 없습니다. 정확한 문제 일지 모르지만 아마 좋은 아이디어가있을 것입니다. 가정에서 나쁜 냄새가 나면 문제의 원인을 찾을 때까지 코를 따라 가고 그것에 대해 무언가를합니다. 같은 방식으로, 코드에 문제가있는 경우 문제가 적거나 아름답 거나 잘 만들어진 코드가 될 때까지 코드를 조사하고 변경하십시오 .

반면에 코드 소유권은 심각한 문제가 될 수 있습니다. 감독이 부족하고 코드 소유자가 떠나면 코드에 대한 지식과 코드로 해결되는 특정 문제를 더 이상 회사에서 사용할 수 없게 될 위험이 있습니다. 실제 코드 자체와는 아무런 관련이 없습니다. 이는 기본적으로 데이터 백업을 유지하는 것과 동일한 방식으로 위험 관리 상황으로 귀결되며 작업 소유권 또는 회사의 다른 영역에서 문서 소유권에 동일하게 적용됩니다.

나는 그것의 벌금와 같은 다른 비즈니스 문제를 설명하는 생각 냄새 ,하지만이 있기 때문에 확실히 단지를 의미하지 냄새 가 코드와 함께 할 수 있도록 특별히 가지고.

본인은 작성한 코드에 대해 개인적으로 책임을지는 것으로 Code Ownership을 정의 하고 앞으로 다른 사람들이 귀하의 코드에서 작업 할 것임을 이해합니다 . 이런 식으로 생각하면 a) 해당 모듈의 버그가 다시 추적 될 수 있으며 b) 팀 구성원이 나중에 코드를 수정하는 데 어려움을 겪을 수 있기 때문에 해킹을 작성할 가능성이 적습니다. .

나는 몇 달 전에 블로그 게시물 을 썼는데, 코드 소유권이 없으면 코드베이스가 종종 커먼즈 의 비극에 빠질 것이라고 주장했다 .

코드 소유권에 대한 귀하의 정의에 따라 필자 만 작업 할 수있는 코드를 보유하는 것은 좋지 않습니다.