okkydokkyy
2019-01-16 21:15:16
21
2906

코드리뷰가 불편한 팀원?


안녕하세요.

이제 막 서비스를 준비하고 있는 스타트업에 합류했습니다. 개발 초기단계라서 개발환경이나 문화가 정착이 잘 안되어서 CI/CD 같은 자동화 툴도 세팅하고 소스코드 관리를 위해 Git도 설정했습니다. 그런데, 코드리뷰 같은 페어프로그래밍에 거부감이 있는 개발자가 있어서 어떻게 설득해야 할지 모르겠습니다... 그 개발자 주장은 git history를 깔끔하게 유지한다고 이런저런 노력을 쏟는 것과 코드리뷰 때문에 코드가 merge 안되는 것 때문에 개발속도가 너무 느려진다고 주장을 하고 있고, 저는 그러한 노력들이 오히려 개발속도를 빠르게 한다고 주장했습니다. 우선은 그 분은 공동창업자라서 일개 직원인 제가 한수 무르고 개발을 하고 있지만, 개발할때는 몰랐던 버그들이 수면 위로 나타나면서 진퇴양난의 상황입니다. 커밋 관리도 제대로 안돼서 어디로 revert해야할지 모르는 상황까지 왔습니다. 이제 시작한지 3개월인데 벌써부터 막막하네요.


Okky 선배님들은 코드리뷰 문화를 거부하는 분을 어떻게 설득하셨나요? 또는 코드리뷰 문화를 어떻게 정착시켜야 할까요?

0
1
  • 댓글 21

  • 한량개발자
    644
    2019-01-16 21:31:53

    설득을 해본적이 없는데..

    코드리뷰 문화가 더 퀄리티 있는 결과물과 사전에 이슈가 발견되어 실제 운영에서 안정적인 서비스를 제공할수 있다라는 점으로 어필하면 어떨까요??


    0
  • 독거소년
    2k
    2019-01-16 21:44:05

    revert 위치를 파악 못한다면 commit 코멘트가 잘못되었단 말 밖에..

    0
  • 시인들
    1k
    2019-01-16 22:52:44 작성 2019-01-17 03:16:00 수정됨

    구지 깃으로 형상관리 할 필요가 있을 까요? 음 장점이 뭐죠?? 제가 왜 이런 얘기를 꺼내냐면 깃은 개발 단계애서 공통으로 사용하기엔 부적합한 툴이거든요..완성단계 이후에 관리는 편한데..지금 작성자분이 commit 관리가 꼬여서 어디서 부터 revert 시켜야 할지 모르는 것 또한 명확한 문제점들 중 하나 인데요

    -6
  • vollfeed
    820
    2019-01-16 23:29:10

    이건 개발팀 운영의 실패지 

    깃의 문제나 코드리뷰의 문제가 아닙니다.

    5
  • okkydokkyy
    2019-01-16 23:52:22 작성 2019-01-16 23:54:18 수정됨

    vollfeed 운영의 실패라고 함은 구체적으로 어떤걸 의미하나요? 

    0
  • 사릉합니다
    140
    2019-01-17 00:27:46
    깃 성공적인관리전략 읽어보시고
    코드리뷰는 정말 은행권처럼 심각한 서비스가 아니라면 커밋후 리뷰를 권장합니다.
    2
  • vollfeed
    820
    2019-01-17 00:39:23

    운영을 제대로 하려면 일을 상황에 맞게 하기위한  정책이 있어야죠.

    git history를 깔끔하게 유지한다고

    - 이런일은 하면안됩니다. 게임 세이브파일 명칭 깔끔하게 유지하세요?  별문제없으면 잘 기억나지 않는 커밋을 꺼낼일이 없어야죠. 이름은 아예 개판이 아니면 문제안됩니다.

    코드리뷰 때문에 코드가 merge 안되는 것 

    - 리뷰후 머지와 머지후 리뷰 정책이 있죠. 

    전 개인적으로 머지후 리뷰입니다. 머지 전에 할건 테스트지 리뷰가 아닙니다. 마스터의 변경을 땡겨와서 테스트를하고 이상없으면 바로 넣으면 됩니다. 속도 중시형입니다.

    리뷰후 머지를 하려면 애초에 리뷰시간을 일과에 포함하는 것은 물론 개발인력도 넉넉히 써야합니다. 퀄리티 중시형이죠.


    그러한 노력들이 오히려 개발속도를 빠르게

    - 이런 본인이 격지못한 주장하지 마세요. 체험을 못해보셨기 때문에 책들의 애기는 그대로하시는것 같은데,

    오히려 빠른경우는 퀄리티 문제로 후반에도 프로젝트를 엎고다시해야만하는 경우를 상정했을때입니다. 그러니까 평소 100의 속도로 갈수있지만 그러다가 엎느니 50으로 간다라는거죠. 이런건 책에 나오는 예시 즉 군사, 의료, 첨단과학 류, 초대형 클라우드, OS, DB등 인프라 들이죠. 포텐셜한 문제를 잡는게 목표입니다. 어차피 테스트케이스로는 다 못잡죠.

    웹사이트만들면서 저러면 진짜 느려질뿐입니다. 포텐셜한 문제는 교과서의 예시들에 비하면 거의 없는 수준입니다. 사실 환경문제와 설계 부실이 주된 문제인데 이건 코드 리뷰로 못잡아요. 차라리 해보면 경험치가 쌓고 엎고 다시하면 더 잘나오죠. 게다가 어떤 상황에서도 동작하는 것을 만들기보다, 적당한 상황에서 동작하는것을 만들텐데요. 에러뱉고 다시하면 되니까요.


    글쓴분과 상사분 모두 상황에 맞지않는 정책을 하나씩 가져와서 옳다고 싸우니, 일이 될리가요.

    이거말고도 상황에 맞는 운영 정책은 많죠. 

    근데 은총알은 없습니다

    8
  • hmmhmmhm
    200
    2019-01-17 00:40:35

    보안문제가 있거나 당장 Release 적용되는게 아니라면

    메인스트림 개발자는 Pull request 없이 개발하는게 맞는거 같습니다.

    오류여부와 코드 커버리지 분석결과를 CI 에서 자동 진단하게하고,

    코드리뷰는 마일스톤 단위로 진단하는 개념으로 하시는게 어떨까요?

    1
  • 아이엠원석
    30
    2019-01-17 01:58:32

    저또한 커밋후에 리뷰를 권장합니다. 저희팀도 그러고 있습니다

    3
  • kiete1
    379
    2019-01-17 09:23:41 작성 2019-01-17 09:24:17 수정됨

    상황과 중요도에 따라 머지 후에 리뷰해도 되는 게 있고 머지 전에 리뷰해야되는 게 있어요

    1
  • 메이슨
    49
    2019-01-17 09:56:51

    코드 리뷰는 애초에 불편한 행위가 맞습니다. 불편해 하는것은 당연한 것이고 그 불편을 대가로 퀄리티 있는 코드를 유지하자는게 목적인거죠. 불편하다는것 자체를 문제삼는건 잘 이해하지 못하고 있거나 목적이 전도된 상황 같습니다. 

    2
  • 야만용녀
    144
    2019-01-17 10:59:34

    코드리뷰를 진행할 선임개발자는 있구요?

    프알못들 모여서 코드리뷰 갑론을박 재밌겠다ㅋㅋ

    0
  • mirheeoj
    7k
    2019-01-17 11:27:55 작성 2019-01-17 11:44:23 수정됨

    왜 그 사람은 코드리뷰 필요성에 대한 공감을 못할까요?

    그건 아마도 문제발생시 자신이 고치지 않기 때문이겠죠. (...) 

    족족 걸려서 족족 자기 일이 커지면 리뷰 하지 말자 해도 하게 되어 있거든요.



    과연 이 부분을 바꿀 수 있을지? 공동창업자라면.. 


    1
  • pooq
    2k
    2019-01-17 11:32:03

    설득(이라 쓰고 억지 강요라고 읽는다)하려고 하지 마시구요,

    스스로 이해하고 필요성을 느낄 수 있도록 예시를 만드세요.

    일단 개인 혹은 몇몇만 모여서 개별적으로 코드 리뷰를하고, 그로인해 발생하는 장단점을 기록하고 공유하면서 다른 사람들의 참여를 유도해야지, 좋은거니까 무조건 하자고 하면 반발만 생기죠.



    1
  • 샬쿰
    110
    2019-01-17 11:43:16

    예전에 옥히에서 코드리뷰는 장단점이 존재한다는 글을 본적이 있는거 같아요 그때 내용은 코드리뷰는 프로그램의 퀄리티는 높아지는 장점이 있으나 과도한 코드리뷰는 장기적으로 개발시간이 길어지는 단점도 존재한다~ 라는 내용의 글이었는데  글의 요지는 코드리뷰를 하느라 정작 중요한 개발일정에 차질이 생겨서는 안된다는 거였죠 개발이 주가 아닌 코드리뷰가 주가 되버린 경우를 경계하라는 뜻 이죠 

    물론 적당한 선에서의 코드리뷰는 필수라고 생각하는 1인입니다.

    1
  • angularts
    117
    2019-01-17 12:37:01

    형상관리로만 따지면, 개인적으로는 git이 최고라고 생각합니다.

    sourcesafe, svn, mercurial, alienbrain까지 여러 버전컨트롤 프로그램들을 운용해 봤지만, git만큼 편리한건 처음인것 같네요.

    물론, github, tower 처럼 운용해주는 여러 툴들의 훌륭함이 한몫 한것이구요.

    이런 편리함을 선입견이나 두려움때문에 아직 도입하지 못한 그룹들이 제게는 안타까울 정도로 좋게 느껴집니다.

    프로젝트 시작에 쓸모없다는 의견도 있는데, 형상관리라는 툴을 너무 크게 보시는것 같네요.

    형상관리는 개인적으로 하는 작은 테스트 프로젝트에도 시작부터 적용하는 버릇을 길러야 한다고 생각합니다.

    git에서의 한가지 단점이라고 생각하는점은 sub module이 너무 불편하다는점 밖에 없네요.

    2
  • 이뉴
    464
    2019-01-17 14:06:51 작성 2019-01-17 14:08:19 수정됨

    안타까운 얘기지만 국내 현실상

    코드 리뷰 하면서 새로운 프로젝트 진행하는 건 불가능하다고 보여집니다.


    애초에 그런 문화를 겪어 온 사람이 거의 없어요

    그리고 프로세스를 바꾸려면 점진적으로 물들이 듯이 천천히 진행해야 거부감이 덜 합니다.

    더군다나 결정권자도 아니기 때문에 말이죠.

    굳이 한다면, 유지보수 할때 기능 추가나 개선 할 때 정도가 그나마 저항이 덜 할 겁니다.


    뭐든지 새로운 걸 추구하거나 도입할 땐 현실적으로 판단하고 가능한 부분 혹은 이득이 되는 부분을 조금씩 개선하는게 베스트케이스라고 생각합니다.

    2
  • okkydokkyy
    2019-01-17 19:55:26 작성 2019-01-17 19:58:05 수정됨

    오우.. 하루사이에 많은 분들이 댓글을 달아주셨군요. 조언해주신 댓글에 일일이 감사하다는 답변을 달수가 없네요. 감사합니다 🙏


    0
  • 초무쿤
    2k
    2019-01-18 00:03:41 작성 2019-01-18 00:07:04 수정됨

    책에서 나오는것과 현실과의 갭 차이라고 보시는게..맞을듯.

    사실 실무에서는 운영할때 말고 개발할때 그렇게 하는 케이스는 못본듯 합니다. 

    페어 프로그래밍 말은 그럴듯 하지요. 실무에서 그렇게 하면 미칩니다.-__-;

    보통 열정에 넘치신 신입분들이나 2-3년 되신분들이 

    책에서 나오는 이야기들을 듣고 그대로 하자고 하실때 

    경력자들이 반대하는 케이스가 있다면 한번 보통 2가지 케이스중 하나일텐데.

    1.경력자들이 잘 모르거나

    2. 이미 실패한 경험이 수두룩한 고수거나.

    둘중 하나에요.. 1인지 2인지는 그사람 개발스킬 보시면 바로 알수 있습니다.

    그거 판단 못하시면 정책결장하는 사람의 능력 문제지요.

    근데 저같아도 않합니다 ㅎㅎ;

    1
  • jja
    2k
    2019-01-18 02:22:28 작성 2019-01-18 02:23:28 수정됨

    애초에 코드리뷰를 왜 하는지 모르겠음...

    코딩규칙 맞추려고하면 모를까. 왜 해요?

    apm으로 문제를 찾고 하면 이해라도 하겠음(10분안에 쇼부)..보나마나 난장토론일텐데 말이죠.

    개발자분들도 타이핑만 치지말고 생각을 많이 합시당~

    프로그램설계&기획 6 개발 1 테스트 3 비중으로 가야 그나마 쓸수있는 수준이 나오는듯...

    그리고 회사에서 커밋된 소스를 보면서 코딩 절친도 찾으세요.. 남이 하는 것 안보나요;

    0
  • dongwoo00
    163
    2019-01-20 03:56:36 작성 2019-01-20 04:04:46 수정됨
    8년차개발자입니다.
    머지전코드리뷰면 개발속도가 느려지는 것 맞습니다. 오히려 개발속도가 빨라진다고 주장하시는 걸로봐선 글쎄요.... 연애를 글로만 배웠어요 같은 느낌이에요.
    코드리뷰는 엄연히 시간과 노력이 들어가는 task인데도 불구하고 task로 인정못받고 야근을 발생시키는 요인들중에 하나가 되는 경우를 봐온지라 많이 부정적입니다. 어떤 개발자가 a라는 일을 하고 있는데 중간에 다른이의 코드리뷰를 꼭 진행해야 되는 일이 생긴다면 정당하게 그 코드리뷰에 소요된 시간만큼 a라는 일이 끝나는 날짜를 더 뒤로 조정하는게 정상이라고 생각합니다.
    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.