‘개발하기’ 종료! 그 다음은..?
이번 8기 BaseCamp 6주차는 ‘개발하기’ 주간을 마치고 이를 시연하는 시간과 코드 리뷰를 통해 ‘개발하기’ 단계에서 작성한 코드들을 점검하고 리팩토링하는 시간을 가졌다.
단순히 ‘어떻게든 돌아가게 구현해야 한다…!’는 생각에서 벗어나서, 코드를 좀 더 주의 깊게 보고 ‘잘 돌아 가는 코드이지만 정말로 그럴까? 다른 문제가 없을까? 왜 이렇게 개발했을까?’ 하는 생각을 가지려고 노력했던 한 주였다.
정적 분석 도구와 테스트 코드 작성하기
Jenkins와 SonarQube라고 하는 정적 분석 도구를 처음 접하게 되어 너무나도 신기했던 한 주였다. 특히 Jenkins의 경우는 이름만 많이 들어 봤고 실제로 본 적이 한번도 없었는데, 막상 보니 처음에는 이게 대체 왜 필요한 걸까 의문이 들기도 했다. ‘여러 프로젝트를 단순히 편리하게 관리하기 위함일까?’ 하는 단순한 생각이 들었다. 하지만 점차 익숙해지면서 느낀 점은, 테스트 코드를 Jenkins에서 직접 실행시켜 주고 그 결과를 SonarQube에 전달해 주는 구조로 되어 있었다. 또한 여러 조의 상황도 볼 수 있었고 빌드의 실패/성공 여부도 손쉽게 확인할 수 있었다. 결정적으로 git과 연동이 되어 누가 무엇을 했는지가 기록에 다 남아 있는 것이 인상적이었다.
SonarQube에서는 code smell과 bug를 지적해 주는 것이 인상깊었다. 물론, test coverage를 나타내는 부분도 처음에는 중요하게 생각했지만, 멘토님의 피드백도 그렇고 운영진분들의 피드백 시간에서 단순히 test coverage의 수치 자체를 높이는 것은 큰 의미가 없다는 이야기를 들었다. Test coverage의 수치는 단순히 테스트 코드 안에서 테스트할 함수가 잘 쓰이고 있는지의 여부로만 판단하기 때문이었다. 이것보다는 직접 given-when-then 방식 등의 절차를 거쳐서 여러 상황에 대해 생각해보고 assertJ 등을 통해서 사용자가 테스트 결과를 확인하고 판단해야 하는 것이 아니라, 컴퓨터가 알아서 테스트가 잘 되었는지의 여부를 판정하도록 짜야 한다는 사실을 알게 되었다.
흔히 TDD라고 해서 개발시 테스트 코드를 같이 고려하고 설계하면서 진행하는 방식을 많이 접하기도 하고 때로는 이러한 방식이 권장되는데, 왜냐하면 개발자가 이 메소드를 어떤 의도로 작성했는지를 테스트 코드를 통해 판단할 수 있기 때문이다. 또한 테스트 코드를 짜면 여러가지 상황(케이스)들을 고려해야 할 수밖에 없기 때문에 더욱 완성도 높은 코드가 나온다는 장점이 있었다. 앞으로도 테스트 코드를 잘 활용해서 더 나은 코드를 짜려고 한다.
지난 개발하기 단계에서 짰던 코드 리뷰
코드 리뷰 단계에서 내가 짰던 20줄짜리 파일 입출력 코드가, 사실은 Spring에서 제공하는 @Value annotation으로 2줄만에 끝낼 수 있다는 사실을 알게 되었다. 코드 리뷰 중 나에게는 가장 충격적인 코멘트였는데, @Value annotation의 경우 분명히 베이스캠프 1주차 사전과제에서 사용했던 것이기 때문이었다. 막상 ‘개발하기’ 주간에 바쁘게 진행되다 보니 생각나는 대로 코딩을 했었는데 너무 조급해하지 말고 더 고민해보고 책을 뒤적거렸어야 했다는 아쉬움이 남았다. 코드 리뷰를 통해서 느낀 바가 몇 가지 있었는데, 우선 다른 팀원의 코드를 내가 신경을 많이 쓴다고 보긴 했는데 리뷰시간에 본 코드는 또 다른 시각에서 읽혔고 직접 팀원의 설명을 듣고 나서야 이해가 되는 부분도 많았다. 또한, 내가 내 코드를 말로 설명하는 것도 결코 쉬운 일이 아니라는 것을 다시금 깨닫게 되었다. 분명히 git에 commit한 사람은 나라고 되어 있는데, 내가 왜 저렇게 코드를 짰을까? 이를 답하기 위해 잠시 생각해보는 시간을 거치는 등 바로바로 나오지 않고 전후 코드를 본 뒤에야 말할 수가 있었기 때문이다.
인텔리제이 단축키와 기능에 익숙해지기
이번 주차에는 내가 조장을 맡아서 코드 리뷰시 리뷰어의 역할을 진행했는데, 원할한 진행을 위해서 인텔리제이의 단축키를 숙지해야 한다는 공지가 올라왔었다. 그래서 사전에 여러 블로그 글을 뒤져보고 직접 단축키를 쳐 보면서 익숙해지려고 노력했는데, 막상 코드 리뷰시에 사용하는 단축키의 종류가 더 많고 다채로웠다. 함수/변수/메소드의 정의부로 이동하는 단축키인 option + B, 함수/변수/메소드의 사용위치를 나타내는 단축키인 command + option + B에서 시작해서, 자바 파일 안에서 ResponseEntity가 어떻게 정의되어 있는지 또한 인텔리제이로 확인할 수 있었고, 앞에서 언급했지만 ‘Annotate with Git Blame’ 이라는 기능을 통해서 특정 코드를 누가 git에 커밋했는지 또한 확인할 수 있었는데 정말 신기했다. 다르게 말하면 이러한 기능들이 사전에 익숙하지가 않아서 코드 리뷰시에 약간 지연되는 문제가 있었는데 팀원들에게 미안했다. 이러한 과정들을 거치면서 인텔리제이에 더더욱 익숙해지고 키보드만으로 많은 것을 해결해보도록 하려고 한다. 마치 vi 단축키에 익숙해지는 것이, 오히려 마우스를 같이 사용할 때보다 더 능률이 오른다는 이야기처럼 말이다.