여러분의 소스코드는 안녕하십니까?
Programming / 2009. 11. 24. 13:33
10년 묵은 잘못된 소스코드 관리
- 소스코드 관리 리소스 증가 : 새로운 기능이 개발되거나 버그가 발생했을 경우 매우 많은 저장소에 동일한 수정과 동일한 테스트를 해야합니다.
- 저장소별 히스토리 관리 : 저장소 별로 수정 히스토리를 따로 관리해야 합니다.
- 같은 문제가 번복됨 : 1번을 잘 못할경우(잘 못하고 있습니다.) 같은 버그가 여러 사이트에서 발생합니다.
즉, 유지보수에 굉장히 많은 리소스가 투입되며, 매출 증가 대비 필요한 리소스는 계속 증가하게 됩니다.
이는 10년동안 지속되온 문제입니다.ㅠㅠ
해결하기
다행히도 제가 생각하는 해결방법과 팀장님이 생각하는 해결방법은 동일했습니다. (팀장님은 이상적 방법이라는 표현을 쓰시긴했지만...) 해결 방법은 다음과 같습니다.
- 메인 소스코드를 버전별로 관리한다.
- 사이트 혹은 BMT에 대응하는 경우 현재 버전의 소스를 복사하여 작업한다. 단, 메인이 되는 소스코드와 동기화는 맞추어야 한다.
- 소스코드는 일정한 주기로 버전 업을 한다. (약 4주)
- 사이트에서 생성되는 요구사항은 일정한 주기로 버전 업 되는 메인 소스코드에 구현한다. 완료되고 적용될 때에는 기존의 복사된 소스코드를 삭제하고 새로운 버전의 소스코드를 복사하여 해당 사이트에 유지한다. (버전 업)
즉, 사이트별로 중복된 소스코드를 사용하지만, 메인 소스코드에 집중하고 잘 유지함으로써 지속적으로 동기화 될수 있는 방법입니다.
10년동안 바꾸지 못한 이유
위의 제시된 방법에서 큰 신뢰성이 요구되는 부분이 있습니다. 사이트의 소스코드를 버전업 하는 경우 기존 기능의 안정성 여부 및 타 시스템간의 호환성 유지 여부가 매우 중요하게 됩니다. 10년동안 바꾸지 못한 이유는 바로 이 점을 QA조직에서 개발팀을 신뢰하지 못하기 때문입니다.ㅠㅠ
이제 개발팀이 해야 할 일들이 눈에 보이기 시작합니다.
- 회귀테스트를 유지하고 관리해야 합니다. 자동화된다면 정말 좋을 겁니다. (TDD 강추..ㅠㅠ)
- 하위 버전 호환성 테스트를 유지하고 관리해야 합니다. API가 변경되지 않는다면 더욱 좋을 겁니다.
어제 회의에서 팀장님께 강력하게 요청했는데 어떻게 반응하실지는 두고봐야 겠네요..^^ 간만에 강하게 나가니까 좀 당황하신듯...ㅋㅋㅋ 10년동안 방치된 방법을 바꾸는게 쉽지는 않겠지만 이대로 간다면 살아남기 쉽지 않기 때문에 뭐라도 해야겠죠..^^
'Programming' 카테고리의 다른 글
| Broken Window Theory and Software (4) | 2009.11.26 |
|---|---|
| 개발언어와 개발스타일 (5) | 2009.11.23 |
| Subtype Polymorphism과 성능 이슈 (4) | 2009.11.17 |