나는 결국 공개 소스가 될 비공개 프로젝트를 진행하고 있습니다. 우리는 몇 명의 팀원을 보유하고 있으며 앱을 구축 할 수있는 기술을 충분히 갖추고 있지만 깨끗하고 아름답고 가장 중요한 장기 유지 보수 코드를 작성할 수있는 전담 개발자는 아닙니다.
코드베이스를 리팩터링하기로 설정했지만 정기적으로 연락하지 않는 다른 국가의 팀원이 완전히 별도의 것을 업데이트 할 수 있기 때문에 약간 다루기 힘들습니다.
하나의 솔루션이 신속하게 의사 소통하거나 더 나은 PM 관행을 채택하는 것임을 알고 있습니다. 코드를 정리하고 그가 업데이트 한 내용과 멋지게 병합하고 싶습니다. 지점을 사용하는 것이 적합한 계획입니까? 최선의 노력? 다른 것?
답변:
사람들이 종종 고려하지 못하는 한 가지는 깨끗한 아키텍처가 장기적인 유지 관리 속도를 높일뿐만 아니라 현재 개발 속도를 높이는 것 입니다. 동료들이 "완료"될 때까지 변경 사항을 격리하려고하지 마십시오. 변경 사항이 있으면 생산성이 높아지고 버그가 발생하기 쉽습니다.
대규모 리 팩터를 수행 할 때 사람들이 가장 자주 저지르는 실수는 한 번의 "빅뱅"에서 시도하는 대신 자주 병합하지 않는 것입니다. 이를 수행하는 올바른 방법은 가능한 한 가장 작은 리 팩터를 만들고, 테스트 한 다음 동료의 지사에 병합하고, 변경 사항에 대해 가르쳐서 앞으로 통합 할 수 있도록하는 것입니다. 이상적으로는 하루에 한 번 또는 적어도 일주일에 한 번 병합하는 것이 이상적입니다.
당신은 결코 "커뮤니케이션하기에 충분히 크지 않습니다". 손가락으로 타이핑을 할 수 있다면 입술도 말을 할 수 있습니다. 하루가 끝나면 기술 개선은 85 %의 커뮤니케이션과 15 %의 기술입니다. 누군가와의 어려운 대화보다 코딩이 더 낫다고해서 좋은 아이디어라는 의미는 아닙니다. 의사 소통은 실제로 당신이하려고하는 것의 어려운 부분이지만 피하는 것이 아닙니다.
그렇습니다. 지사는 이것에 대한 좋은 해결책입니다.
나는 지점 에서이 작업을 시작하고 HEAD그 동안 현재 위에 깨끗하게 적용하는 것이 좋습니다 (즉, 변경 사항을 쉽게 적용 할 수 있고 테스트가 여전히 통과하도록 정기적으로 테스트 리베이스 및 병합을 수행하십시오- -또한 이것으로 도움을 찾으십시오git rereregit . 그런 다음 리베이스하고 변경 사항을에 병합하십시오 HEAD.
아키텍처를 변경하면 코드가 점점 추워 질수록 점점 더 많은 작업이 이루어 지므로이 작업을 빨리 시작할수록 더 좋습니다. 또한 코드 기반 전체에 흩어져있는 수작업으로 코딩 된 코드의 인스턴스가 많을 수 있습니다. 예를 들어 새롭고 더 밝은 도우미 기능으로 인해 훨씬 간단 해졌습니다.
tl; dr-빅 리그로 올라갈 때가 된 것 같습니다. 돼지에 립스틱을 바르더라도 그런 종류의 일이 아니라면 더 예쁘지 않습니다 ...
사람들 문제
첫 번째 문제는 커밋 동기화입니다. 여러 사람이 같은 코드에서 동시에 작업하는 경우 문제를 방지하기 위해 규칙이 하나만 필요합니다.
Rule 1: Always pull before you merge/rebase
DVCS의 경우, 원격 브랜치 (예 : 메인 리포지토리)를 변경하기가 어렵고 로컬을 변경하기가 매우 쉽습니다. 모든 사람은 자신의 코드 추가를 문제없이 전체에 적용 할 책임이 있습니다. 두 사람이 동시에 커밋하지 않는 한 경험하지 마십시오. 원산지 / 원격 마스터에 대한 커밋 액세스는 소수의 개발자로만 제한되어야하며 원격 추적 분기를 통해 다른 개발자로부터 변경 사항을 가져와야합니다.
코드 문제
변경 사항이 코드를 위반하지 않는다는 것을 어떻게 알 수 있습니까?
간단한 대답은 ... 그렇지 않다는 것을 증명하는 테스트를 작성하십시오. TDD (Test Driven Design) 사고 방식을 무시하면 테스트의 요점은 코드를 손상시키지 않고 코드를 변경할 수있는 검증 수준을 추가하는 것입니다.
Rule 2: Don't make assumptions, write proofs (ie tests).
이외에도 원점 / 원격 마스터로 푸시하기 전에 전체 테스트 영역을 실행해야합니다.
커밋을 작고 간결하게 유지하십시오. 이렇게하면 나중에 문제가 발생한 변경 사항을 취소해야하는 경우 코드를 손상시키지 않은 부분을 다시 구현하지 않아도됩니다.
먼저 조직 구조 조정이 필요할 수 있습니다.
위의 솔루션을 쉽게 적용 할 수 없다면 개발 구조와 관련하여 먼저 해결해야 할 문제가있을 수 있습니다.
프로젝트 소유자는 게이트 키퍼 여야합니다. 커밋 동기화 문제가있는 경우 커밋 액세스 권한이있는 사람이 너무 많을 수 있습니다. Linux 커널과 같은 대규모 프로젝트에서도 소수의 개발자 만이 원본 / 원격 마스터 리포지토리에 액세스 할 수 있습니다. 커밋을 관리하기 위해 실제로 여러 레벨의 저장소가 있습니다. 모든 사람이 변경 사항을 원점으로 푸시하는 단일 레이어 커밋 모델 대신 계층 모델에는 프로젝트에 포함되기 전에 변경 사항을 가져 와서 품질을 확인하는 게이트 키퍼가 있습니다. 계층 적 커밋 모델은 품질을 유지하면서 단일 레이어 모델보다 훨씬 더 크고 효과적으로 확장 할 수 있습니다.
액세스를 저지되지 않는 DEVS를 들어, 그들은 자신의 원격 추적 브랜치 만들 배워야한다 (자식과 gitorious이를 위해 좋다)을 DEVS 있도록 할 쉽게 풀 수있는 액세스를 저지 한 / 원점으로 가지를 통합 할 수 있습니다. 변경 사항이 작 으면 패치도 작동합니다.
병합 / 리베이스를 수행하기 전에 변경 사항을 가져 오는 기능은 로컬 마스터 브랜치에서 개발 중이 아니라고 가정합니다. 이를 처리하는 쉬운 방법은 코딩을 시작하기 전에 초기 풀을 만든 다음 해당 지점에서 모든 작업을 수행하는 것입니다. 어려운 방법은 병합하기 직전에 분기하고 마스터를 롤백하는 것입니다.
프로젝트 전체의 코딩 스타일을 정의하고 개발자가이를 따르도록합니다. 기여하는 개발자는 정리를 최소화하기 위해 프로젝트 표준 / 규범에 맞는 코드를 작성해야합니다. 코딩 스타일은 열린 프로젝트에서 큰 자아 장벽이 될 수 있습니다. 표준을 설정하지 않으면 모든 사람이 선호하는 스타일로 코딩하고 코드베이스가 매우 빠릅니다.
"신화적인 남자 달"의 신화
믿거 나 말거나, 더 크고 성공적인 오픈 소스 프로젝트는 민주주의처럼 운영되지 않습니다. 계층 구조로 실행됩니다. 8-10 명 이상의 개발자가 프로젝트를 효과적으로 성장시킬 수 없다고 말하는 것은 순진합니다. 그것이 사실이라면 Linux Kernel과 같은 거대한 프로젝트는 존재하지 않을 것입니다. 더 깊은 문제는 모든 사람에게 커밋 액세스 권한을 부여하면 효과적인 커뮤니케이션을 처리하기가 어렵다는 것입니다.
신화적인 남자 달의 문제는 실제로 극복 될 수 있습니다. 군대처럼 프로젝트를 실행하면됩니다. 계층 내에는 개인이 소수의 사람들과의 커뮤니케이션을 관리하는 데에만 효과적이라는 것이 일반적인 지식이기 때문에 여러 계층이 있습니다. 개인이 5 ~ 7 명을 초과하는 작업을 관리 할 책임이없는 한 시스템은 무한정 확장 할 수 있습니다.
최고의 / 경험이있는 개발자가 더 많은 통합 및 더 높은 수준의 설계 / 계획을 수행하도록 제한 할 수 있지만 이는 나쁘지 않습니다. 확장의 일부는 프로젝트에 장기 계획이 필요하다는 결정을 내리는 것입니다. 미래의 프로젝트에 가장 많은 투자를하는 최고 수준의 사람들 (시간은 또한 자원이기도합니다)은 큰 결정을 내릴 책임이 있습니다.
점점 더 많은 고통을 겪고있는 오픈 소스 프로젝트에 대해 들어 보니 기쁩니다. 축하하고 행운을 빕니다.
깨끗하고 아름답고 가장 중요한 장기 유지 보수 코드.
내 경험상 깨끗하고 아름다운 것은 유지 보수의 적입니다. 아름다운 코드 :
반면에 유지 관리 가능한 코드는 다음과 같습니다.