[우리는 코드 리뷰를 하지 않습니다.] 꽤 재밌는 글이라 가져와 봅니다. 조금은 독한 맛도 있는 문화인 것 같습니다. 실제로, 코드 리뷰를 전혀 하지 않는 회사도 여전히 많이 있습니다. 허나,

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