(펌) 어떻게 하면 더 나은 소프트웨어를 만들 수 있을까?

어떻게 하면 더 나은 소프트웨어를 만들 수 있을까? – 인터뷰 시리즈 part 1, Fernando Jimenez Moreno와 함께

출처 : http://hacks.mozilla.or.kr/2014/08/how-can-we-write-better-software-interview-series-part-1/
영문 원본 : https://hacks.mozilla.org/2014/07/how-can-we-write-better-software-interview-series-part-1/

Telefonica에서 근무하고 있으면서 MozillaOS 개발에 참여하고 있는 사람의 인터뷰 기사
Code Reviewer 업무를 함에 있어 참고할 만한 좋은 내용이 많아 옮겨 본다.

우리가 모질라와 함께 일한 것은 2011년으로 거슬러 올라갑니다. 두 회사 모두에게 잘 맞는 공통된 작업 절차를 찾기까지 꽤 많은 시간이 걸렸습니다. 제말은, 우리는 텔코(telco) 문화에서 일하던 사람입니다. 텔코 문화에서는 대부분의 작업들이 폐쇄적이고 비밀입니다. 이것은 모질라의 공개적이고 투명한 문화와는 반대죠.

Telco 문화가 왜 폐쇄적이어야 할까? Telco 문화가 폐쇄적이라기 보다 Mozilla와 같은 Web 기반 기술을 사용하는 회사나 조직의 문화가 공개적이고 투명한 게 아닐까 싶다. Telco가 아니라 자동차 산업도 폐쇄적일 거라고 생각

우리는 텔레포니카에서 애자일 방법론을 쓰고 있었는데, 당시 모질라는 애자일 방법론을 쓰고 있지 않았습니다. 우리는 양쪽 모두에게 맞는 작업 절차를 찾아야 했습니다. 그러기 위해 꽤 많은 시간이 필요했습니다. 작업 절차에 대해 의논하기 위해 아주 많이 만났고, 아주 많이 토론했습니다. 다른 텔코 회사들과 일하는 것의 경우는 지금까지 무척 만족합니다. 특히 텔레노르와 잘 협조하고 있습니다. 아직까지 우리는 그들(텔레노르)과 정보를 공유할 때 조심합니다. 왜냐하면 궁극적으로 그들은 우리의 경쟁사니까요. 하지만 그렇다고 해서 파이어폭스 계정 시스템 개발 같은 공동의 목표를 위해 협조 못한다는 말은 아닙니다.

Telefonica가 Agile을 사용하고, Mozilla가 그렇지 않다는 게 의외네. 반대가 아닐까 싶었는데 NFV관련 내용을 봐도 그렇고 Telefonia가 상당해 개발 지향적인 듯

많은 원칙이 적용되고, 많은 회사가 참여하는 프로젝트의 경우 스타일가이드, 도구, 프로세스 등의 공통 표준이 얼마나 중요한가요?

글쎄요, 나는 소프트웨어 엔지니어링에 대해 일반적으로 말할 때 표준이 중요하다고 합니다. 하지만, 나는 그것을 SCRUM이라고 부르던, KANBAN이라고 부르던, SCRUMBAN이라고 부런던 상관하지 않습니다. 마찬가지로 Git 워크플로우를 따르던, Mercurial 워크플로우를 따르던, 아니면 구글의 자바스크립트 스타일가이드를 따르던, 모질라의 자바스크립트 스타일가이드를 따르던 상관하지 않습니다. 어떤 공통의 프로세스와 표준은 반드시 필요합니다. 특히 대규모의 엔지니어링 그룹의 경우는 더욱 그렇습니다. 오픈소스 프로젝트나 모질라 프로젝트가 이에 해당합니다. 공통 표준에 대해 말하자면, 규칙은 매우 간단합니다. 보통의 경우 이런 표준과 공통 프로세스들을 정의하고 토론하는데 너무 많은 시간을 소비하는 나머진 진정한 개발 목표를 잃어버리는 수가 있습니다. 나는 이런 공통 표준이 결국은 도구일뿐이라는 사실을 잊으면 안된다고 생각합니다. 우리 개발자들과 우리 매니저들을 돕는 도구지요. 공통 표준에 대해 유연하게 접근하는 지혜가 필요합니다.

우리는 코드를 리뷰할 때 코딩 스타일을 많이 보곤합니다. 하지만 결과적으로 우리가 원하는 것은 코드를 수정해서 문제를 해결하는 것입니다. 만약 코딩 스타일에 문제가 있다면 고치면 됩니다. 연습삼아 패치를 남기는 상황이라면 일단 패치 코드를 버그 시스템에 기록으로 남겨 두세요. 그러면 코드 리뷰어가 기회 있을 때 코멘트할 것입니다.

다소 모호한 답변인 듯. 표준이 필요하다는 듯 한데 또 그 표준에 대해서는 유연하게 접근하자는 말. 모호하다. 동시에 여러 style을 사용해도 문제가 없다는 건지
당연히 코딩 스타일보다 동작을 보는 게 중요하지. 코딩 스타일에 문제가 있으면 고치면 된다는 말은 코드도 문제가 있으면 고치면 된다는 거랑 뭐가 다른 걸까?

코드를 리뷰할 때 무엇을 살펴보나요?

일반적으로 제가 가장 먼저 확인하는 것은 정확성입니다. 그러니까, 패치 코드는 원래 의도했던 문제를 실제로 해결해야 합니다. 그리고 당연히 부가적인 문제를 일으켜서는 안됩니다. 어떤 회귀적 문제도 일으켜서는 안됩니다. 시간이 허락되면 패치 코드를 제가 직접 테스트합니다. 패치 코드가 어떻게 동작하는지 알고 싶어서 이기도 하고, 아주 중요한 패치 코드일 경우 제대로 동작하는지 회귀적 문제를 일으키지는 않는지 확인하고 싶어서 이기도 합니다. 또 코드가 효율적으로 동작하는지 안전한지 살펴봅니다. 패치 코드에 대한 테스트 슈트 작성이 가능해 보이면 거의 언제나 테스트 슈트 작성을 요구합니다. 마지막으로 전반적인 코드의 품질, 문서, 코딩스타일, 기여정도, 프로세스의 정확성 등을 살펴봅니다

직접 리뷰어가 테스트까지 한다는 게 의외(?). 가능하면 언제나 테스트 슈트 작성을 요구한다는 것이 인상적이다.

당신은 지금까지 제가 겪은 다른 어떤 리뷰어보다 더 일관성을 강조했습니다. 다른 어떤 리뷰어보다 말이죠.

글쎄요. 일관성은 코드의 전반적인 품질을 향상시킵니다. 리뷰할 때, 나는 종종 “nit:”라는 코멘트를 남깁니다. 이건 모질라에서 아주 일반적인 코멘트인데, “이 코드를 수정하면 좋겠습니다. 만약 수정하지 않더라도 리뷰 결과는 긍정적입니다. 하지만 이 코드가 조금 더 수정되기를 희망합니다.”라는 뜻입니다.

동작은 하겠지만, 수정했으면 좋겠다라는 의미. 나도 이런 코멘트를 많이 하는 편인데 사람에 따라 받아들이는 게 달라서 고민. 물론 이렇게 의켠을 주는 거슨 받아들이는 사람이 판단하라는 의미이긴 하지만…

개발자로서 당신은 엄격한 리뷰를 배우는 기회로 삼으려 했단 말이지요? 그렇다면 리뷰어로서 리뷰를 가르치는 수단으로 사용하기도 했나요?

예, 물론입니다. 그러니까 패치 코드를 리뷰하는 것은 가르치는 일입니다. 리뷰어는 코드를 작성한 사람에게 옳다고 생각하는 것을 말하는 것입니다. 때때로 코멘트를 뒷받침할만한 이론이나 이유가 불분명할 때도 있지만, 리뷰어는 자기 주장을 해야 합니다. 리뷰어는 가능한 최선의 이유를 설명해야 하고 최선의 진보를 이뤄내야 합니다.

코드 리뷰어의 의견은 코드 리뷰어의 생각을 말하는 것. 당연히 잘못된 생각이 있을 수 있으므로. 다만 위 글처럼 근거가 부족한 경우 설득하기 어렵다. 개발자들은 누구보다 자존심이 강하고 자신만의 스타일을 가지고 있는 것들이라.