(개콘의 한 코너 패러디)
A : 15년 S/W 역사를 가진 우리 팀은 S/W 품질 향상을 위해 최신 기술을 도입하고 있어요
B : 정말이예요. 그래서 이제는 소스 변경할 때마다
- 변경사유
- 추가된 라인 수
- 변경된 라인 수
- 삭제된 라인 수
- 최종 라인 수
- 추가된 코멘트 수
- 삭제된 코멘트 수
- 최종 코멘트 수
를 엑셀에 기록하라고 한다니깐요.
Clearcase는 폼인가? Diff나 Patch는 어디에 쓰려고?
속이 터지려고 한다.
추가) 알고봤더니 저런 “실행계획”을 만든 분은 Clearcase가 뭘 해주는 지를 전혀 모르고 있단다. 뭘 해주는 지 모르니 시스템을 신뢰도 하지 못하고 일일이 수기로 기록해야 모든 걸 믿을 수 있나 보다. 그런 분이 그 위치에 있으니 참 깝깝하다.
개발자가 수정하거나 새로 개발한 내용을 여러 브랜치에 적용하지 않아 발생하는 문제를 봐와서 저렇게 “관리”하고 싶은 마음은 이해하겠지만 그건 MR(Modification Request) 번호만 제대로 관리해도 쉽게 해결할 수 있는 문제다.
통상 개발자들이 코드를 수정하기 위해 MR을 따고, source 코드에 대한 unlock 요청을 한 후 해당 MR의 내용만 수정하지 않고 이런 저런 다른 내용도 수정하는 경우가 있다. 그러면 MR 사용에 대한 관리를 강화하면 된다. 해당 MR에 대한 필요한 코드 수정만 했는지, 필요한 브랜치에 해당 MR의 내용을 모두 적용했는지 등.
ㄷㄷㄷ
뭘 하는 걸까요? 내일 부장님께 이야기를 한번 해보려구요. 뭘 알고 싶은 거냐고
그 많은 내용을 엑셀에 기록이라.. ㅎㅎㅎ
기능 개발이나 버그를 알아도 귀찮아서 수정하지 않으려구요 -_-