tag:blogger.com,1999:blog-6060875800282210631.post1017151685918753524..comments2023-11-08T05:29:09.590+09:00Comments on All of Software: 소스코드관리 상세 조사 결과 리포트전규현http://www.blogger.com/profile/02706025917864233238noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-6060875800282210631.post-31362123537039610662009-03-09T08:15:23.000+09:002009-03-09T08:15:23.000+09:00예상대로 코드리뷰에 대한 결과는 저조하군요. 흠...예상대로 코드리뷰에 대한 결과는 저조하군요. 흠...헝그리맨http://www.codereview.co.krnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-50414427356806661862009-03-09T10:31:53.000+09:002009-03-09T10:31:53.000+09:00헝그리맨님 안녕하세요.코드리뷰는 가장 정착시키기 어려운 개발문화 중의 하나입니다. 실리콘밸...헝그리맨님 안녕하세요.<br>코드리뷰는 가장 정착시키기 어려운 개발문화 중의 하나입니다. 실리콘밸리에서도 귀찮기는 마찬가지이지만, 규칙으로 정해 놓고 누구나 따릅니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-79884686484781217282009-03-09T09:44:12.000+09:002009-03-09T09:44:12.000+09:003번 Rule 에서 8,9번 항목의 경우 처음 질문 때 의도가 명확치 않으면 구분해서 쓰지...3번 Rule 에서 8,9번 항목의 경우 처음 질문 때 의도가 명확치 않으면 구분해서 쓰지 않고 중복 체크를 할 것 같습니다만. <br>그리고 버그트래커-버전관리툴 이 연동된 시스템을 쓰는 개발자 입장에선 버그 번호를 쓰는게 더 쉽습니다. 아무 설명도 안쓰고 버그 번호만 쓰면 되거든요. (상세 내용은 어차피 버그트래커에서 계속 덧글로 달리므로. 그리고 버그 트래커와 버그 번호 연동되는 시스템인 경우 버그 번호만 룰에 맞춰 남기는게 훨씬 보기에도 좋고 추적성 면에서도 좋습니다. 그리고 SVN Log 로 쓸 수 있는 텍스트 양은 한계가 있습니다. 차라리 별도 문서를 남기죠) <br>3 way merge 의 경우.. 툴 자체가 편하긴 하나, 자동 테스트가 구축되고 커밋 빈도가 높은 곳의 경우 그냥 눈으로 비교하는 것으로도 충분합니다. (한 changeset 당 코드 변화량이 적은 경우) changeset 당 코드 변화량과 conflict 단위가 큰 경우 툴의 편의성 문제로 보기보다는 그렇게 conflict 단위가 크게 가는 상황 자체가 문제일지도 모르죠.<br>그리고 질문이 있다면.. '팀/프로젝트 규모 대비 필요한 만큼의 성숙도' 의 기준이 정해진 것이 있는지 궁금합니다.[1002]noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-12632025984793667132009-03-09T10:40:30.000+09:002009-03-09T10:40:30.000+09:00좋은 의견 감사합니다.8,9번 항목의 경우 실제로 그렇게 하고 있는 개발자라면 다 이해를 ...좋은 의견 감사합니다.<br>8,9번 항목의 경우 실제로 그렇게 하고 있는 개발자라면 다 이해를 할 것입니다. 제대로 하고 있는 곳이라면 8,9번을 다 체크하겠지요. <br>머지는 팀이 커질수록 머지에 많은 노력이 들어가는데, 눈으로 비교해서 머지하는 것은 시간도 많이 걸리고 실수의 가능성도 크다고 생가가합니다. 팀이 커지고 동시에 많은 사람들이 소스코드를 중복해서 수정하더라도 Conflict가 가능하면 적게 생기도록 하는 것이 좋습니다. 이런 경험이 쌓이면 자연스럽게 어떻게 해야 Conflict가 적게 생기는지 요령이 생깁니다.<br>3,4명의 개발자들이 동시에 개발하는 팀에서는 어떻게 해도 큰 문제가 되지는 않습니다. 개발팀이 커질 수록 신경을 써야겠지요. <br>제가 소프트웨어공학 컨설팅을 하기 때문에 '팀/프로젝트 규모 대비 필요함 만큼의 성숙도'에 대한 기준은 가지고 있습니다. 하지만 많은 회사들이 그 기준에 미치지 못하고, 발생하는 수많은 문제를 피해 다님으로서 스스로의 생산성과 역량을 떨어뜨리는 결과를 가져오고 있습니다. 팀의 규모와 역량에 알맞은 규칙과 툴을 적절하게 이용하면 훨씬 더 생산성을 높일 수 있는데, 심지어는 자신만의 세계에 갇혀서 이러한 변화를 거부하는 개발자도 많답니다.Ray.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-78172390700436531512009-03-11T11:52:59.000+09:002009-03-11T11:52:59.000+09:00안녕하셔요?이제는 개발자에서는 조금 멀어진 애 늙은이 입니다.^^제가 종사하는 분야에서는 ...안녕하셔요?<br>이제는 개발자에서는 조금 멀어진 애 늙은이 입니다.^^<br>제가 종사하는 분야에서는 아직도 주먹구구식으로 개발이 이루어지고 있습니다.<br>후배들에게는 체계가 갖추어진 환경을 물려주기 위해 공부 중입니다.<br><br>그런데, 코드리뷰는 어떻게 해야 하나요?<br>막연한 질문이지만, 간단히 설명 부탁드립니다.<br>혹시, 좋은 무료도구가 있을까요?<br>집필하신 책을 주문했는데, 그 안에 답이 있을까요?<br><br>그리고, 버그추적시스템을 소개와 비교 부탁드립니다.<br><br>감사합니다.한인철noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-3362536411896529982009-03-11T13:40:37.000+09:002009-03-11T13:40:37.000+09:00한인철님 안녕하세요.코드리뷰는 가장 필요하면서도 매우 정착시키기 어려운 개발문화입니다. 코...한인철님 안녕하세요.<br>코드리뷰는 가장 필요하면서도 매우 정착시키기 어려운 개발문화입니다. 코드리뷰는 종류가 여러가지고 있고, 개발 조직에 따라서 알맞은 방법을 써야 하며 제도적으로, 시스템적으로 뒷받침이 필요합니다. 여러 도구가 있기는 하지만 당장 도구가 없어서 코드리뷰를 못하는 것은 아닙니다. 일단 시작하는 것이 중요하고 시작하기 위한 기본적인 지식은 갖춰야죠. 좀더 구체적인 것이 필요하면 연락주세요.<br><br>그리고 버그추적시스템은 제 책에도 소개가 되어 있고, 현재 투표가 진행중인데, 투표가 끝나면 글을 올릴 예정입니다.<br><br>감사합니다.Ray.전규현http://allofsoftware.netnoreply@blogger.com