소프트웨어 게발을 하면서 하는 활동들이 다음과 같이 있다.
모두 중요하지만 가장 중요한 것은 코딩이다. 실질적인 결과물이 있어야 하기 때문이다. 그다음으로 중요한 것은 문제를 정의하는 일인데 우리가 코드를 작성하는 이유가 문제를 해결하는 일이기 때문이다. 그래서 문제를 정확하게 정의하고 요구 사항을 잘 파악하는 게 중요한데, 이에 집중하는 것이 TDD다. 구현이 먼저 가 아닌 우리가 원하는 목표에 대해서 테스트를 작성하고 그 테스트를 통과시키기 위해 온갖 노력을 다해야 한다.
혼자 피보나치 수열에 대한 문제를 풀고 2명씩 짝을 지어 코드 리뷰를 하였다. 코드 리뷰는 잘하는 사람이 못하는 사람에게 알려주려고 하는 것이 아닌 서로를 잘 알기 위해서 한다는 말이 좋았다. 혼자 코드를 작성할 때는 넘어갔던 부분도 상대방이 납득해야 하기 때문에 자세히 설명하면서 각 단계를 세세하게 구분할 수 있었다. 이러한 코드 리뷰를 실시간으로 바로 할 수 있는 것이 짝 프로그래밍이다.
그다음에는 2명이서 짝 프로그래밍을 했고 한 명이 관찰자 시점에서 지켜보면서 코멘트를 해줬다. 내가 해당 코드를 작성하는 의도와 이유를 자세하게 설명하면서 햐려다보니 각 단계가 더 세세하게 나뉘었다. 리팩토링을 할 때 그냥 매직넘버를 없애는 리팩토링을 했는데 따로 설명하고 하지 않았다. 관찰자분이 왜 그렇게 리팩토링을 했는지에 대해 여쭤봐서 매직넘버를 없애기 위해 리팩토링을 했다고 했다. 나는 이미 알고 있던 것들을 상대방에게 설명하지 않고 코드를 작성했다. 다음번에는 더 설명하면서 해야겠다.
셀프코드리뷰에 대한 얘기도 나눴는데 예전에 회사에서 다른분의 코드리뷰를 하다가 잘못 작성한 코드에 대해서 코멘트를 작성했다. 근데 알고보니 내가 올린 풀리퀘스트에도 똑같이 잘못한 코드가 있었다. 웃긴 상황이었는데 이 때 이후로 셀프코드리뷰를 하기 시작했다. 편집기에서 작성할 때 보는 것과 깃헙에서 보는 것은 또 다른 느낌이었다. 다른 사람이 내 코드를 보기전에 혹시 이해하기 어려운 부분에 대해서 셀프로 코멘트를 남기고, 잘못된게 있는지 확인하기 위해 셀프코드리뷰를 한다.
내가 만든 것은 VS Code Wiki였는데 나는 사실 기획이나 사용자 스토리를 많이 생각하지 않고 바로 개발을 시작했다. 왜냐하면 이미 만들어진 Vim Wiki를 많이 참고했기 때문이었다. 다른 분들은 사용자의 요구 사항을 파악하는 데 노력을 많이 했다. 사용자 입장에서 어떻게 사용할지에 대해 더 집중해서 개발을 진행해야겠다.
CoeceptJS는 이미 해본 적도 있고 내 사이드 프로젝트에 설정이 다 되어 있는데 테스트 코드를 많이 작성하지 않았다. 기술적인 것보다는 인수 테스트를 작성하여 개발을 하는 방법을 많이 연습하고 익혀야 겠다.
만약 내가 백엔드 개발자이라고 생각하고 프런트 개발자가 어떤 API가 필요하다고 한다면 인수가 프런트개발자가 하니까 프런트개발자를 위한 인수 테스트를 작성해야 하나 생각이 들었다. 하지만 인수 테스트는 사용자 입장에서 사용할 때를 테스트하는 것이다. 실제 업무에서는 프런트 개발자와 백엔드 개발자가 같이 협업을 하여 인수 테스트를 작성해야 한다.
BDD 스타일의 테스트도 살펴봤는데 TDD보다 우리가 원하는 것에 더 집중해서 작성할 수 있어서 좋았다. 또 Happy path를 작성하다 보면 예외들이 생각이 나는데 예외를 작성할 때 더 작성하기 쉽게 틀이 잡혀 있는 느낌이었다.
유지 보수하기 쉽도록 의존성 방향을 만드는 것을 많이 얘기했다. 내가 작성한 코드에서는 많이 고려돼있지 않은 것 같았다. 내가 규모가 큰 애플리케이션을 만들어보거나 살펴보지 않아서 그런 것 같다. 예전에 UI가 이미 이렇게 되어 있기 때문에 도메인을 변경해야 한다는 개발자의 말을 들은 적이 있었는데 더티 아키텍처가 생각났다.
자바스크립트로 직접 만들면서 배우는 - 자료구조와 알고리즘 강의 바로 가기
실습으로 마스터하는 OAuth 2.0: 기본부터 보안 위험까지 - OAuth 2.0 강의 바로 가기
기계인간 이종립, 소프트웨어 개발의 지혜 - Git 강의 바로 가기
코드숨에서 매주 스터디를 진행하고 있습니다. 메일을 등록하시면 새로운 스터디가 시작될 때 알려드릴게요!
