[우리는 코드 리뷰를 하지 않습니다.] 꽤 재밌는 글이라 가져와 봅니다. 조금은 독한 맛도 있는 문화인 것 같습니다. 실제로, 코드 리뷰를 전혀 하지 않는 회사도 여전히 많이 있습니다. 허나, 이렇게 선언적으로 "리뷰를 하지 않습니다"라고 이야기한 곳은 보지 못했던 것 같습니다. 제가 독한맛이라고 표현한 건, "책임과 자유"라는 표현에 있습니다. 제 경험상 개인이 코드 오너쉽을 갖는다는 건, 비슷한 실력 수준의 동료들과 일하면서, 정말 높은 수준의 신뢰가 바탕이 되지 않으면 동작하기 어려웠습니다. 그리고 무엇보다.... 신뢰 수준이나 코드 퀄리티를 떨어뜨리는 사람을 조금은 냉정하게 자를 수도 있어야겠죠(그것이 책임일수도...) 하하하 <💡 핵심 요약> Raycast는 코드리뷰에 대해 스스로에게 여러번 물어봤고, 하지 않기로 했습니다. 우린 같은 공간에서 일하는 것부터 시작했었고, 높은 신뢰 수준을 갖고 있습니다. 때문에, 모든 엔지니어는 main으로 push할 권한과 책임을 가지게 됩니다. 우리가 생각하기에 Github PR 리뷰는 다음과 같은 문제가 있습니다. - 높은 신뢰수준을 가진 우리팀에 신뢰를 오히려 떨어뜨립니다. - PR이 버그를 막아주진 않습니다.. - PR이 점점 속도를 저하시킵니다. 우리는 대신 엔지니어에게 전적인 책임을 주는 것을 중요하게 생각하며, 자유와 책임(전적인 책임에 가까움)을 주었습니다. 그리고, 아래를 중요시 여기기로 했습니다. - 매일 개밥 먹기 (push된 모든 건 다음날 아침에 Daily Build를 통해 확인) - 격주 Release 업데이트(고객에게 제공되는)를 제공해서 빠른 피드백을 받습니다. - PR을 금지하는 건 아닙니다. 새로운 작업에 대해선 PR을 하기도 합니다. - 엔지니어들의 의견이 필요할 땐 화상 및 화면 공유로 바로 공유합니다. 중요한 건 우리 뿐만 아니라 여러분 모두 가능한 짧은 시간에 최고의 제품을 만드는 것이 목표일 것입니다. 이를 달성하는 다양한 방법이 있는데, 우리는 엔지니어에게 전적인 책임과 자유를 주는 것을 선택했습니다.

No code reviews by default

Raycast

No code reviews by default

2022년 1월 15일 오전 11:19

댓글 2

  • 오 완전 신선해요!!! Pr이 버그를 막아주지 않는다니 ㅜ 충격이네요

  • 기업 인하우스 전문직군들에게 공통적인 현상이 존재한다는 것을 알게 됐습니다. 특히 <HARD CODE>란 책을 읽으며, 그리고 IT개발직군에 계신 분들의 글들을 읽으며 용어만 다르지 디자이너와 개발자가 일하는 방식에서, 유관부서와 일하는 프로세스나 관계, 일하는 환경 등 유사한 점을 많이 발견합니다. 개발자들이 개발문화라고 강조하는 것처럼 디자이너들도 디자인문화에 대한 중요성을 늘 강조하고 있거든요. (그리고 여담으로, <HARD CODE>란 책을 읽을 때는 얼마나 무릎을 치며 3M 플래그를 페이지마다 붙였는지 책 사이드면이 알록달록해졌답니다. 개발자분들은 이미 알고 계실 분들이 많을 것 같은데 디자이너들도, 특히 디자인 디렉터라면 꼭 필독하시기를 권해 드리며 디자인과 밀접하게 일하시는 마케터나 기획자 리더분들 가운데 디자인에 대한 이해도가 높으신 분들은 흥미롭게 훑어 보실 수 있을 것 같습니다. 분야는 다르지만 개발자를 디자이너로 치환해서 읽으면 우리가 하는 일과 어느 정도 연상이 되실 겁니다.) 시사점이 크네요. 너무 흥미롭게 좋은 글 잘 읽었습니다. :)

주간 인기 TOP 10

지난주 커리어리에서 인기 있던 게시물이에요!