코드 재사용 및 문서를 홍보하는 방법? [닫은]

10 명 이상의 개발자로 구성된 팀장으로서 코드 재사용을 장려하고 싶습니다. 우리는 많은 코드를 작성했습니다. 지난 몇 년 동안 많은 코드가 반복됩니다. 문제는 이제 이러한 코드 중 많은 부분이 다른 코드와 중복되거나 약간 변형 된 것입니다.

미래의 프로젝트에 재사용 할 수 있도록 코드를 컴포넌트로 만드는 방법에 대한 움직임 (토론)을 시작했지만 문제는 컴포넌트를 모르는 새로운 개발자 나 다른 개발자가 앞으로 나아가고 자신의 것을 쓰십시오.

어쨌든 개발자가 기존 코드를 복제하고 수정하거나 자체 코드를 작성하는 대신 구성 요소를 재사용하거나 문서를 개선하며 기본 구성 요소에 기여하도록 상기시켜 주어야합니까?

모든 사람이 사용할 수 있도록 구성 요소를 쉽게 검색하고 사용하기 쉽게 만드는 방법은 무엇입니까?

모든 개발자가 재사용 가능한 구성 요소의 이점에 대해 알고 있고 사용하기를 원한다고 생각합니다. 검색 가능한 구성 요소를 만드는 방법을 모르는 것입니다. 또한 개발자는 코드를 작성할 때 재사용 가능한 코드를 작성해야하지만 그렇게하는 동기가 없다는 것을 알고 있습니다.

적절한 문서가 필요합니다. 쉽게 찾고 탐색 할 수 있어야합니다. 또한 훈련이 필요합니다. 재사용 가능한 코드 라이브러리에 이미 솔루션이 제공되었지만 개발자가 적절한 이유없이 자체 솔루션을 사용하기로 선택한 경우 솔루션을 되돌리고 기존 솔루션을 사용하도록 지시해야합니다.

또한 질문에 대한 Euphoric의 의견에 동의합니다. 서로 다른 프로젝트간에 어떤 것도 재사용 할 수없는 경우가 많습니다 (보통 모든 CRUD 작업은 동일하게 보이지만 일반적으로 재사용 할 수는 없습니다).

이미 언급 한 "문서", "찾고 쉽게 탐색 할 수있는", "징계"및 "코드 검토"요인

재사용 가능한 코드는

• 사용하기 쉬움 (= 예 : 단위 테스트 필요)
• 다른 모듈에 너무 많은 의존성 이없고
• 라이브러리를 사용하기 위해 응용 프로그램을 업데이트 할 필요가 없도록 안정적인 API 가 있어야합니다 .

마지막 두 항목이 없으면 "복사 및 과거 상속"을 사용하는 것이 훨씬 쉽습니다.

실제로 코드를 재사용하는 가장 좋은 방법은 동기 부여라고 생각합니다. Euphoric이 제안한 것처럼 재사용 가능한 구성 요소를 추가 프로젝트에 넣는 경우 많은 노력을 기울이십시오. 내가 일하는 곳에서 구성 가능한 실행 계획에서 사전 정의 된 인터페이스 세트를 실행하고 몇 가지 서비스 (예 : DB_interaction, FTP-Service 등의 다른 클래스)를 제공하는 프로젝트를 만들었습니다. 우리 개발자들이 실제로 마이크로 프레임 워크를 사용 하기 를 원 하기 때문에이 프로젝트는 큰 성공을 거두었습니다 . 비슷한 프로젝트를 위해 상용구 코드를 작성하는 데 많은 시간을 절약하기 때문입니다. 목록, 문자열 등의 유틸리티 라이브러리도 마찬가지이지만이 경우 기존 라이브러리를 한 번만 사용하려고합니다. (왜 창을 재발 명합니까?)

결론 : 개발자가 잘 테스트 한 재사용 가능한 구성 요소의 이점을 경험할 수 있습니다. 그러나 나는 Andrzej Bobak의 대답에 동의합니다. 많은 것들이 비슷하지만 동일하지 않기 때문에 재사용 할 수 없습니다.

사람들 은 간단한 구성 요소를위한 새로운 코드를 작성하고 자신의 방식대로 하는 것을 좋아 하기 때문에 어려울 것입니다. 새로운 요구 사항으로 완전히 새로운 구현을 작성하는 것보다 기존 솔루션을 활용하고 확장하는 것이 훨씬 어렵습니다. 이미 언급했듯이 팀간에 코드 검토 프로세스를 시작하여 기존 구성 요소를 새 구성 요소 대신 사용 / 확장해야하는 상황을 식별하는 데 도움이됩니다.

또한 사람들이 문서를 참조 하고 필요한 것을 쉽게 찾을 수 있도록 매우 훌륭하고 철저한 문서를 유지 해야합니다. 문서가 불완전하거나 실제 내용과 동기화되지 않은 경우, 사람들은 문서를 검색하거나 향상 시키려고하지 않습니다.

또한 팀 리더로서 사람들이 자신을 만들기 전에 유사한 구성 요소가 있는지 물어보고 문서를 찾아 보도록 지시해야합니다. 누군가가 기존 구성 요소를 놓친 경우 코드 검토 프로세스가이를 포착 할 수는 있지만 이미 10 시간의 개발을 자체 구현에 적용한 경우 어떻게해야합니까? 팀에서 좋은 연구 행동을 시행하여 이러한 상황을 피해야합니다.

우리는 현재 작업중 인 큰 프로젝트 에서이 문제에 직면했습니다. 우리는 지난 몇 개월 동안 개발자를 로테이션했습니다. 또한 매우 큰 코드 기반이며 처음부터 프로젝트에 참여한 사람들조차도 모든 부분을 알지 못합니다.

코드는 종종 잘 작성되고 단일 책임으로 작은 부분으로 나뉘어지고 설명서가 있지만 수행 된 작업을 놓치는 것은 매우 쉽습니다. 일관된 이름 지정 규칙은 모든 IDE에서 쉽게 찾을 수 있기 때문에 많은 도움이됩니다. 문서는 포괄적 일 수 있지만 길어질수록 문서를 읽는 데 약간의 어려움이 있습니다.

한 가지 우리가, 내 의견으로는, 그렇게했던 상황이 크게 우리가 부르는 물건의 도입이었다 개선 번개 회담 . 누군가 팀에 알려야한다고 생각하는 코드를 작성할 때마다 짧은 (보통 5-15 분) 프리젠 테이션이 준비됩니다. 우리는 매주 한 번씩 이것을하려고합니다. 주제는 테스트 / 코딩 접근법, 재사용 가능한 구성 요소를 통해 최근 발생한 복잡한 문제를 처리하는 새로운 기능 및 방법에서 앱의 기초 및 리팩토링에 대해 이야기하기까지 다양합니다.

특정 주제는 회사 전체의 유사한 대화에서 언급됩니다. 우리는 지식 공유를 촉진하는 매우 효율적인 방법을 찾았습니다. 짧은 프리젠 테이션을보고 기억하고 훨씬 길고 드물게 개최되는 교육 세션에 참여하거나 거기에 앉아 문서를 읽고 읽는 것보다 추가 문서를 찾을 위치 또는 도움을 구할 사람을 아는 것이 훨씬 쉽습니다.

실제로 회사 차원의 대화가 먼저 이루어졌습니다. 우리는 방금 프로젝트 별 지식 공유를 위해이 접근 방식을 채택했으며 잘 작동한다고 생각합니다.

페어 프로그래밍은 또한 지식 순환을 훨씬 빠르게 만듭니다.

나는 이것이 실제로 두 가지 질문이라고 생각합니다. 나는 두 가지에 모두 대답하려고 노력할 것입니다.

1) 코드베이스에서 중복 코드를 줄이는 방법은 무엇입니까?
이렇게하면 비즈니스 로직이 중복되어 버그가 줄어들고 코드를 유지 관리 할 필요가 줄어든다는 이점이 있습니다. 이를 방지하는 가장 좋은 방법은 다른 답변에서 언급 한 것처럼 의사 소통을 통하는 것입니다. 본인은 지식을 올바르게 전파하기 위해 코드 검토 책임을 동등하게 공유해야한다는 추가 경고와 함께 코드 검토를 사용하는 것이 좋습니다. 또한 유용한 코드가 존재하는 문제를 누군가가 해결할 때 개발자가 종종 인식 할 수 있도록 매일 스탠드 업을 사용해야합니다. 또한 지식 공유를 늘리고 프로그래머를 훈련시키는 데 도움이되는 코드 쌍을 고려해야합니다.

또한 가능하면 같은 방에서 가능한 한 가깝게 개발자를 만나는 것이 좋습니다. 많은 공유 화이트 보드와 공간. 그런 다음 함께 식사를 위해 보내십시오. 개발자가 "결합"할수록 서로 더 잘 커뮤니케이션 할 수 있습니다.

Wiki 또는 문서 코드와 유사한 것을 사용하는 것이 좋습니다. 아무리 훈련 된 개발자가 문서화를 시도하더라도 원래 코드에서 벗어나게됩니다. 보다 효과적인 접근 방식은 예제 스타일 테스트에서 스펙을 사용하는 것입니다. 여기에는 코드를 사용해야하는 방식을 명확하게 설명하는 코드가 문서화되어 있으며, 예제를 변경하지 않고 코드를 변경하면 테스트가 실패합니다.

이미 중복 코드가 많은 대형 코드베이스가 있으므로 리팩토링 작업을 수행해야합니다. 잘라내어 붙여 넣지 않은 중복 코드를 찾기가 어려울 수 있습니다. 따라서 변경 기록을 분석하는 것이 좋습니다. 자주 변경되는 파일을 찾습니다. 실제 중복 코드를 나타내지 않고 정리할 가치가 있으면 캡슐화에 문제가 있음을 나타냅니다. 코드 변경 사항에 대해 버그 수정 기록을 분석 할 수 있으면 수정이 필요한 특정 핫스팟이있을 수 있습니다. 이러한 핫스팟을 분석하면 많은 비즈니스 로직이 개발자가 한 곳에서만 변경 한 두 번의 변경이 필요하다는 사실을 깨닫지 못하고 중복 된 비즈니스 로직으로 인한 것입니다.

2) 다른 프로젝트에서 사용할 수있는 공유 위젯, 컴포넌트, 라이브러리 등을 만드는 방법은 무엇입니까 ?
이 경우 비즈니스 로직을 래핑하지 말고 유용한 프레임 워크 코드를 공유해야합니다. 공유 구성 요소 집합을 만들고 유지 관리하는 데 드는 비용이 상당히 클 수 있으며 수행 할 가치가있는 인스턴스를 예측하기가 어려울 수 있기 때문에 이는 까다로운 균형이 될 수 있습니다. 여기서 제안하는 접근법은 3 가지 파업 규칙입니다. 비슷한 코드를 두 번 작성하는 것에 대해 걱정하지 말고 세 번째로 수행해야 할 때 공유 구성 요소로 리팩토링하십시오. 이 시점에서 이것이 유용 할 것임을 확신 할 수 있으며 구성 요소에 대한 광범위한 요구 사항을 잘 알고 있습니다. 분명히 개발자들 사이의 의사 소통은 여기서 매우 중요합니다.

가능한 많은 공유 구성 요소를 오픈 소스로 만드십시오. 비즈니스 로직이 아니므로 경쟁사에게 많은 이점을 제공하지는 않지만 추가 검토 자와 유지 관리자를 무료로 얻을 수 있습니다.

IMMO의 핵심은 문서 나 도구가 아니라 통신입니다. 10 명 이상의 개발자는 많은 사람들이 아니고이 의사 소통을 향상시키는 것들은 다음과 같습니다.

• 페어 프로그래밍 : 두 사람과 함께 두 사람 중 하나가 프로젝트의 다른 부분에서 이미 해결 된 문제를 알고 재사용한다는 더 많은 변화가 있습니다.

• 집합적인 코드 소유권 : 모든 사람들은 시스템의 다른 부분들과 함께 작업합니다. 이런 방식으로 프로젝트의 다른 부분에서 이미 수행 된 작업을 아는 것이 훨씬 쉽습니다.

• 수평 프로젝트의 작업 시간 (예 : 한 달에 금요일 1 ~ 2 일)을 부여하면이 시점의 개발자는 회사 프로젝트에 적용 할 수있는 자신의 프로젝트에서 작업 할 수 있습니다. 이 방법으로 개발자는 재사용 가능한 라이브러리 및 구성 요소를 작성할 수 있으며 때로는 이미 존재하지만 약간의 정리 및 문서화가 필요한 코드를 작성할 수 있습니다.

• 대화 및 워크샵 만들기 : 개발자 대화 및 워크샵을위한 시간을 예약하십시오. 개발자는 자신의 라이브러리에 대해 이야기하거나 워크샵을 리팩터링하고 중복 코드를 작성하고 중복을 제거하여 재사용 가능한 구성 요소를 만들 수 있습니다.

문서는 아마도 필요하지만 실제로 필요한 것 중 작은 부분 일뿐입니다. 팀 내부의 커뮤니케이션을 향상시킵니다.

Lucene과 같은 로컬 검색 엔진 (또는 소스 코드에 특정한 것)을 사용하여 코드를 색인화하는 것은 어떻습니까? 누군가 새로운 클래스 나 새로운 함수를 작성하기 시작하면 (예를 들어) 자신의 코드를 작성하기 전에 몇 가지 검색을 시도해야합니다 (내부 정책으로). 이렇게하면 너무 많은 의사 소통을 피할 수 있으며 좋은 주석, 메소드 및 클래스 이름에 의존 할 수 있습니다. 인터넷에서 사용할 수있는 오픈 소스 검색 엔진을 사용하여이 작업을 수행하고 있음을 알 수 있습니다. 누가 메서드 나 클래스의 이름을 무엇이라고 썼는지 모르지만 몇 가지 검색이나 동의어를 사용하면 항상 필요한 것을 찾을 수 있습니다.

개발자가 매끄럽게 작업 할 수 있도록 도와주는 도구가 필요합니다. 개발자가 사용하기 쉬운 효율적인 도구를 통해 코드 작성뿐만 아니라 품질 보증, 통합 등을 위해 코드 스 니펫을 재사용하여 절약 할 수있는 시간을 발견 한 경우 개발 환경에 직접 통합되면 그러한 도구를 채택하도록기도 할 것입니다!

코드 재사용을위한 라이브러리 구현이 여러 번 큰 이점이되지 않도록주의하십시오 (너무 강력하고 커지는 경향이 있습니다). 대신 간단한 스 니펫, 즉 특정 작업을 효과적인 방식으로 해결하는 몇 줄의 코드에 집중하고 싶습니다.

이러한 방식으로 프로그래머가 직접 사용할 수있는 실제 예제를 제공하여 지침 및 모범 사례를 강제로 사용할 수 있습니다.

스 니펫 관리를위한 몇 가지 도구가 있습니다. http://www.snip2code.com을 추천합니다 .

(면책 조항 : 저는 Snip2Code의 창립자 중 한 사람이며 공동 창립자와 함께-얼마 전에 같은 생각을 가지고 있었기 때문에 우리 가이 프로젝트를 시작하기로 결정한 이유는 모든 기능을 수집합니다. 위에서 언급 한, 즉 팀간에 스 니펫 공유, Visual Studio, Eclipse, IntelliJ, Notepad ++ 등과 같은 IDE 통합