조직은 공통 구성 요소를 어떻게 처리합니까?

Question

공통 구성 요소는 라이브러리 또는 한 그룹이 생성하고 유지 관리하고 많은 그룹에서 사용하는 다른 코드입니다.

우리가 가진 몇 가지 문제는 다음과 같습니다.

• 사용자는 구성 요소에 문제를보고하지 않습니다.
• 사용자는 자신의 요구에 맞게 구성 요소에 대한 해결 방법을 구축합니다.
• 그들은 마감일을 충족시키기 위해 트렁크 버전과의 호환성을 깨뜨립니다.
• 사용자는 자신의 (덜 강력한) 솔루션을 코딩하게됩니다. 솔루션이 더 좋다고 생각하기 때문입니다.

조직은 공통 구성 요소를 어떻게 처리합니까?

내가 가진 아이디어 :

• 구성 요소를 오픈 소스 프로젝트처럼 취급하고 팀이 패치를 제출하도록 요구합니다.
• 코드에 대한 사용자 정의 수정을 완전히 허용하지 않습니다.
• ...

Answer 1

여기에있는 것은 기술적 인 문제보다는 인적 요소 문제 일 수 있습니다. 실제로 그것은 주로 학습 문제 일 수 있습니다 (여기서 발명되지 않은 전형적인 증후군과 함께).

대기업에서 일한 후, 나는 새로운 사람이 그에게 이용할 수있는 모든 자원 (즉, 공유 코드 라이브러리)을 이해하는 것이 어렵다는 것을 알고 있습니다.

새로운 고용이있을 때는 공통 구성 요소 라이브러리에서 공식 교육을 받았습니까?

그렇다면 사람들이 보상을받는 문제가 있습니다. 검토 시간에 관리자는 사람들에게 공통 구성 요소를 사용하여 개선하고 개선을 도서관에 다시 제출 한 것에 대해 사람들에게 보상합니까? 또는 관리자가 단순히 자신의 프로젝트에 관심을 갖도록합니까?

공통 도서관을 유지하는 그룹의 경우, 제안하거나 개선을 제출하기 위해 시간을내는 사람들에게 어떤 형태 나 회수를합니까? 그들은 회사 뉴스 레터에 글을 쓰나요? 현금 보너스를 받으시겠습니까? Bulliten 보드에서 사진을 가져 오시겠습니까?

사람들은 인정이나 보상을받지 않는 회사를 위해 무언가를 할 가능성이 거의 없다는 것을 기억하십시오.

Answer 2

우리는 더 많은 서비스 기반 시스템으로 이동하려고 노력하여 하나의 프로젝트에 대한 특정 기능을 만들면 웹 서비스를 통해 다른 프로젝트에서 사용할 수 있습니다. 이렇게하면 코드의 인스턴스가 하나뿐입니다.

당연히 이것은 일부 유형의 구성 요소 (예 : 최근에 PDF 제작 서비스를 만들었습니다)보다 더 잘 작동합니다 (아마도 문자열 조작 유틸리티의 과잉).

Answer 3

내가 여기에서 본 유일한 성공적인 구성 요소는 컴파일 된 버전 (*.dll)으로 재분배됩니다. 사용자는 소유 팀과 직접 버그를보고하고 직접 구현합니다. 변경할 가능성이 가장 높은 물건에 대한 자체 플러그인을 작성하는 API가 있으므로 사람들은 많은 경우 기능을 확장 할 수 있습니다.

항상 트레이드 오프가 있습니다

• 사람들이 당신의 구성 요소를 사용하도록 설득하십시오
• 합리적인 수준의 품질을 동시에 유지

귀하의 경우에 가장 좋은 방법은 확실하지 않지만 일반적으로 핵심 논리를 직접 구현하려고 시도하고 구성 요소를 구성 가능/확장 가능하게 유지하여 사람들이 항상 핵심을 변경하고 좋은 지원을 제공 할 필요가 없습니다. 어떤 이유로 어떤 이유로 일부 개발자는 항상 바퀴를 재창조하는 경향이 있지만 어리석은 일이므로 너무 걱정하지 않을 것입니다.

Answer 4

좋은 방법은 정기 코드 검토를 실시하는 것입니다. 이 기간 동안 휠을 다시 발명 한 경우 개발자가 공통 구성 요소에 사용하도록 교육을 교육시킬 수있는 기회 또는 원래 코드에 대한 추론을 동맹해야한다고 생각하는 이유를 사용할 수 있습니다. 이렇게하면 모든 사람의 요구 사항이 이루어지고 모든 사람이 구성 요소가 개선됩니다.

Answer 5

타사 라이브러리와 같은 방식으로 처리하십시오. 나는 다른 팀이 소스를 보지 못하게하지 않을 것입니다. 그렇게하면 많은 시간을 낭비하는 비판과 백 키즈로 이어질 수 있습니다.

Answer 6

조직은 얼마나 큰가요? 나는이 내용이 소규모 조직 (총 수십 명의 프로그래머)에서 매우 잘 처리되는 것을 보았습니다. 여기서 한두 명의 개인이 각 구성 요소의 소유권을 가지고 있으며 기능 요청에 응답하는 것으로 알려져 있습니다.

누군가의 사무실로 행진하고 (또는 우편물), 필요한 것을 설명하고 다음 중 하나를 얻는 것이 더 쉽습니다.

• 원하는대로 예상되는 방법,
• 필요한 기능을 추가하라는 계약 (또는 미니언을 지시하도록)
• 공통 구성 요소에서 필요한 기능을 구현할 수있는 권한

해결 방법을 작성하거나 포크를 시작하거나 동등한 새 구성 요소를 작성하는 것보다. 프로그래머가 똑똑하다면 가장 쉬운 일을 할 것입니다. 요령은 이것이 옳은 일을 보장하는 것입니다.

링크 된 목록과 같은 정말 간단한 것들 외에도, 휠 보장이 많이 진행되지 않았습니다. 특정 제품에 대한 개인 포크가 거의 없었으며, 가장 일반적으로 물건을 잘라내어 코드 크기를 줄입니다. 그러나 일반적인 방법은 원래 구성 요소를 더 많은 빌드 옵션을 갖도록 수정하는 것이 었습니다.