모범적인 코드는 무엇일까?
프로그래머로 일을 하다보면 개발자들끼리 모범적인 코드에 대해 논쟁 하게 되는 경우가 더러 있습니다.
‘어떤 구조가 더 좋다.’ 혹은 ‘이건 실제로 내가 해본 경험이 있다‘등의 다양한 이유로 시작해서 누군가가 내 코드가 더 좋은 코드라고 주장을 한다거나, 당신이 작성한 코드가 모범적이지 않다고 하는 경우, 혹은 서로의 구조를 주장하다가 기분이 상하는 경우도 있습니다.
그래서 많은 코드리뷰 책이나 개발 문화 관련 책에서 “비자아적 프로그래밍(감정을 배제하고)을 해라”, “지속 가능하게 코드를 짜라"등의 이야기를 하곤 합니다.
허나, 실제로 경험해보면 우리가 사람인 이상, 이런 가이드는 유니콘을 찾아 떠나는 것처럼 실질적인 도움이 되지 않습니다. (실제로 비자아적 프로그래밍을 문화로 만들어보려고 했으나 3개월만에 포기했습니다. 다들 너무 많이 상처를 받았거든요.)
그렇다면 모범적인 코드는 무엇일까요?
이번에 제가 길벗으로 부터 지원 받은 “읽기 쉬운 코드"라는 책에서 모범적인 코드에 대한 힌트를 얻을 수 있었습니다. 바로 인간이 읽기 쉬운 코드 = 모범적인 코드 입니다.
“읽기 쉬운 코드"와 더불어 리팩토링의 저자 마틴 파울러가 하는 핵심은 이렇습니다.
“컴퓨터가 인식 가능한 코드는 바보라도 작성할 수 있지만, 인간이 이해할 수 있는 코드는 실력 있는 프로그래머만 작성할 수 있다.”
읽기 쉬운 코드
오늘 소개시켜 드릴 읽기 쉬운 코드 는 책 전반에 걸쳐, 어떻게 하면 인간이 읽기 쉬우면서 내 머리에 적합한 코드를 작성하는 가에 대한 팁들로 가득차 있습니다. 교양과 같은 책인 줄 알았는데, 확실하게 이야기드리면 “실용서"에 가깝습니다. 이 정도까지 디테일해도 되나? 싶은 느낌이 많이 들었던 책은 간만이였습니다.
제가 주로 다루는 C#을 기반으로 책이 작성되어 있어서, 저 같은 경우엔 책을 읽으면서 현재 본업에서 몇가지는 적용도 해보게 되었습니다. 특히, 9장 팀워크는 엔지니어링 리드나 팀장을 맡고 계시다면 꼭 추천해드리는 챕터 중 하나입니다. 지속적인 통합(CI)라던가 작고 많이 커밋하기, 그리고 코드의 공동 소유 개념과 코드 리뷰등 정말 알찬 팁들이 가득했습니다.
책은 모범적 코드에 대한 답을 알려주는가?
책은 전반에 걸쳐 “모범적 코드란 무엇이다!“를 제시하기 보다는 모범적인 코드로 나아가는 방법 경험에 기반해서 제시하고, 읽는 이로 하여금 답을 찾게 해줍니다. 그래서 책의 저자도 그렇고, 추천서를 쓴 마틴도 그렇고, 모든 것의 전제는 소프트 웨어는 어렵다 에서 시작합니다.
그래서 섣불리 모범을 제시하기 보단, 기동성과 더 나은 코드 를 작성하기 위한 실용적인 방법이라던가, 어떻게 코드를 내 머릿속에서 정리하고, 팀에게 잘 전파하는지 등과 같은 코드를 “읽기 쉬운 방향"으로 보내는 방법들에 대해 경험적으로 풀어 나가고 있습니다.
대표적인 예를 들면 테스트를 작성하는 방법이나 테스트 코드를 위해 관심사 분리의 개념에 대한 팁을 이야기하면서 동시에 테스트가 너무나 많아져서 생기는 퇴행에 대해서도 다루는게 이 책의 핵심입니다.
그래서 재밌게도 마틴이 쓴 책 추천서를 보면 이런 내용이 나옵니다.
책을 읽으면서 동의하지 않는 부분을 찾아 내는 것이 얼마나 재밌을지 생각 했습니다. 그리고 정확히 그런일이 발생했습니다. (중략) 하지만 이건 중요하지 않습니다. 요점은 소프트웨어가 어렵다는 것이고, 지난 70년 동안 소프트웨어를 조금이라도 쉽게 만들 수 있는 방법을 찾기 위해 노력해왔다는 것입니다.
저도 이 책을 보면서 “이렇게 까지 해야하나?” 싶은 동의하지 않는 내용도 있었고, “와 이건 실용적이다"라는 것들도 있었습니다. 허나 천천히 음미해보면 전체적인 구성이나 내용들이 실용적인 내용으로 가득차 있고, 간만에 성장한 느낌을 받았습니다.
만약에 여러분이 소프트웨어 개발의 통찰력과, 더 나은 코드를 위한 통찰력을 얻고 싶으시다면 읽어보길 추천드립니다.