최근에 사수님께서 "이제 00도 테스트코드를 짜면서 코드를 짜보세요." 라고 하셨다.

그래서 당연히 넵 :) 이라고 답했다.

근데 "테스트코드를 먼저 짜면서 코드를 작성해보세요" 라고 하셨다.

나 : ???

입사 전에도 테스트코드를 짜보긴 했고, TDD(Test-Driven-Developement)라는 걸 들어보긴 했었다. 근데 이제 사수님이 TDD는 테스트코드를 먼저 짜보면서 코드를 작성하는 거라고 하시면서 한 번 해보라니까 감이 안 잡혔다. 그래서 한 번 TDD를 왜하는 거고, 어떻게 하는지 찾아보기로 했다.

그래서 TDD 왜 해야하는 거야?

전에 혼자 DRF를 이용해서 asset-dashboard라는 프로젝트를 혼자 진행했던 후기 글에서도 언급했듯이 점점 기획의 중요성을 느꼈다. 그래서 어떤 기획이 좋은 기획인가?를 찾아보면서 여러 글을 보았는데 그 중 이런 글귀가 있었다. "가설 베이스 사고를 하는 것이 논리적 사고를 하는데 있어서 중요하다. 늘 결론을 갖고 그에 대한 가설을 검증하는 방식으로 사고해야 한다" 이 글귀가 정확히 TDD가 가고자 하는 방향을 설명하는 것 같았다.

테스트코드를 먼저 짜므로서 가설을 설정하고, 내가 짠 코드로 그 가설을 검증하는 것이다.

그리고 이런 방향으로 개발하기 위해서는 "검증하고자 하는 가설은 무엇인가?" 이게 핵심 질문이였다. 즉, "테스트하고자 하는 것이 무엇인가"이다. 생각해보면 이전에 간단하게 테스트코드를 짤 때는 request를 날리고 requests.code.ok가 떴는지 이런걸 체크하기 위해 테스트코드를 짰었는데 이런게 무의식 중에 생각하게 되는 아주 작은 가설 ('내가 이렇게 request를 날리면 200이 올 것이다!") 중 하나였던 것 같다. "

이렇게 하면 테스트코드를 먼저 짜야하니까 미래에 일어날 버그들을 생각하게 되고, 코드부터 짜고 테스트를 하는 것보다 나중에 생길 버그나 개선해야 할 것들을 더 생각하게 되는 것 같았다. 그리고 결과적으로 모두가 원했던 버그는 줄고 코드는 간결해지는 clean code라는 목표에 다다르게 되는 것 같았다.

마지막으로 이런 이유로 TDD를 하는 것이고, TDD를 하면 미래에 유지보수하는 시간이 매우 줄 것이라고 생각한다. 그래서 기능이 많은 큰 프로젝트에서는 TDD가 중요할 것 같다. 근데 해보니까 TDD를 하면 개발하는 시간이 엄청나게 늘어 날 것 같다. 기획자와 의사소통이 많이 필요하니까... 그래서 프로토타입을 만들어서 기능을 실험해보거나 휘발성이 높은 코드를 짤 때는 엄청 필요할 것 같진 않아보였다.

그래서 TDD를 어떻게 해야하나...

위의 사진처럼 설계/기획하고, 테스트코드를 먼저 작성한 다음에 코드 개발을 하는 것이다. 그리고 더 나아가서 TDD 방식이란 테스트코드를 짜면서 발생하는 예외사항들을 계속 테스트케이스에 추가하면서 설계를 개선하고 마지막에 테스트를 통과한 코드만 실제 코드로 작성하는 방식이라고 한다. 이론적으론 그렇다... :)

사실 이런 부분은 ' 아 그렇구나... 일단 이렇게 해야하는 거 같다...' 이렇게 감을 잡고 하다보면 아 '왜 이런 방식으로 하라고 가르쳐주셨구나...' 라는 걸 더 느끼게 되는 것 같다. 그래서 회사 내부에서 누군가 unittest로 짜놓은 test코드를 보면서 공부하고, 이전에 써보았던 pytest도 생각하면서 일단 어떻게든 해보고 있다. 꼭 알아두면 좋은 setup, setupclass나 teardown, teardownclass와 더불어서 @patch 이런 것도 다음에 글 쓰면서 정리해봐야겠다.

00pen.tistory.com/92

참고문헌

구글에서 개발한 5일 완성 기획 프로세스:  brunch.co.kr/@thinkaboutlove/87

TDD(Test-Driven-Development) 방법론에 대해서: https://wooaoe.tistory.com/33 

개발자로 취업을 하기로 마음 먹은 후 약 7개월이 지나고 파이썬 개발자로 취업을 하게 되었습니다. 컴퓨터 공학을 전공하신 분들에 비해서는 코드 몽키 수준이겠지만 항상 코드 아래서 컴퓨터가 어떻게 돌고 있는지 이해하기 위한 노력을 많이 하다보니 취업에 성공하지 않았나 생각이 듭니다.

아래 제가 밟아 왔던 과정을 자세히 설명하겠지만 결론부터 말하면 Django를 잘 공부하기 위해서는 에듀캐스트에 있는 리액트와 함께 장고 시작하기 (educast.com/course/web-dev/ZU53) 를 정말 추천하고 싶습니다. 22만원이라 좀 비싸다고 느끼긴 했지만 돈이 아깝지 않은 강의입니다.

먼저 저는 학부 때 배워본 건 파이썬 기초 밖에 없었지만 그걸 이용해서 프로젝트를 한 번 해보았으니 이걸 기반으로 갈고 닦으면 충분히 취업을 할 수 있을 거라고 생각했던 것 같습니다. 그래서 독학 아니면 학원을 다니는 선택지가 있었는데 공부를 시작할 당시에는 졸업을 하기 전이라 그냥 독학을 골랐습니다. 학원이 상당히 비싸다고 느끼기도 했고요... 그래서 처음 시작할 때는 nomad coder의 강의들을 들었습니다. (아래는 nomad coder에서 들었던 강의들 후기)

이전다음

01

아무튼 어느 정도 웹 개발이 이런거구나~ 라고 생각할 때쯤 컴퓨터 공학의 기초들의 필요성을 느꼈던 것 같습니다. 뿐만 아니라 몇몇 기업에서는 코딩테스트를 요구해서 먼저 자료구조와 알고리즘을 공부하기로 마음 먹었습니다. 그 때 당시에 막 파이썬 알고리즘 인터뷰라는 책이 나와서 그 책으로 공부했었습니다.

이 책을 통해 공부하면서 파이썬 내부의 standard library들을 알게 되었고, 굳이 다른 패키지를 깔지 않고도 아름다운 코드를 짤 수 있다는 것도 느끼고 magic method에 대해서도 공부하게 되었습니다. 그 후 배워온 Django 기술을 이용해 먼저 취업을 해서 실무 경험을 쌓아보고 싶다는 생각을 하고, Django를 더 깊게 배우기 위해 위에서 추천했던 에듀캐스트의 리액트와 함께 장고 시작하기를 결제하고 강의를 들었습니다.

근데 이 강의를 들으면서 진짜 장고를 배운 것 같다는 느낌이 들었던 건 github에 있는 장고 코드를 같이 보면서 내부에서 어떻게 돌아가는지 프로세스를 가르쳐 주셨기 때문이라고 생각합니다. 근데 이 강의를 듣기 전에 위의 파이썬 알고리즘 인터뷰 같은 책을 통해 파이썬의 문법, 자료구조, standard library의 사용법을 배우고 듣는 것이 좋습니다. 그래야 강의를 100% 이해할 수 있기 때문입니다.

최근에 유난히 코딩을 가르치는 곳들이 많아지고, 가르치는 방식도 다양하다 보니 어느 걸 들어야하는지 고민하시는 분들도 많을 것 같습니다. 컴퓨터 공학 기초를 탄탄히 하고, 응용을 배우는 게 좋다고 생각하지만 저부터 딱딱한 이론 강의를 좋아하지 않다보니 이렇게 마구잡이로 공부했던 것 같습니다. 그래서 다른 분들이 어느정도는 이런 순서로 공부하면 좋지 않을까라는 생각을 하면서 글을 써보았습니다 :)

https://00pen.tistory.com/87

처음에 계획할 때 8월 15일까지 끝내겠다고 했는데 계획은 반은 지켜지고 반은 안 지켜졌다고 할 수 있을 것 같다. 왜냐하면 오류없이 8월 15일까지 만들기는 만들었다. 근데 테스트를 하면 할 수록 조그만한 오점들이 계속 나오는 것 같다. 그래서 직접 테스트하거나 Django Restframework 에서 제공하는 test 모듈로 TDD를 진행하는 중이다.

프로젝트를 끝내면서 느낀 점은 크게 두가지다.

첫 번째는 기획/계획이 굉장히 중요했다는 것. 아이디어이 생각난 후에 이틀 정도 구상한 후 프로젝트를 만들기 시작하였는데 만들면서 Django의 model 부분 즉, Database에 저장될 스키마, 가 여러 번 수정되었다. 그러면서 오류도 많이 생기고 고치는데도 시간이 꽤 소요되었는데 이래서 데이터베이스를 설계하는 사람이 따로 필요한 건지 알게 되었다.

두 번째는 빌드는 빠른데 오류/예외들을 처리하는 것이 더 오래 걸리겠다는 것. 찾아보니 QA 분들이 정석루트를 해피패스라고 부르는 것을 알게 되었는데 나는 해피패스 외에 적은 예외만 처리해 왔다는 것을 알게 되었다. 아주 완벽하게 서비스를 만드려면 대충 다 만들고 Quanlity Assurance에 시간을 많이 투자해야할 것 같다는 생각을 하게 되었다.( 작은 프로젝트에서는 그냥 만들고 일부 사용자들이 사용해보고, 피드백을 받아 고치는 것도 좋다는 것을 알게 됨. )

이제 Django를 어느 정도는 다룰 수 있게 되었다고 생각한다. 하지만 공부하면 할 수록 부족하다는 것이 느껴져 Django도 dbshell과 서버에 deploy하는 것을 더 배우고, 네트워크랑 데이터베이스도 계속 공부해봐야겠다. 아무튼 개인 프로젝트를 만들면서 재밌었고, 끝내서 보람찼다.

Frontend 결과물 예시: https://qhqnf.github.io/asset-dashboard-fe/#

Frontend github: https://github.com/qhqnf/asset-dashboard-fe

Backend 결과물 api 문서: http://asset-dashboard-dev.ap-northeast-2.elasticbeanstalk.com/swagger/

Backend github: https://github.com/qhqnf/asset-dashboard

https://00pen.tistory.com/85

7월 25일에 시작해서 8월 1일로 백엔드를 얼추 다 만들었습니다. 처음으로 혼자서 처음부터 끝까지 만들어보니 기획/계획의 중요성과 디자인 패턴의 중요성도 알게 된 것 같습니다. 왜냐하면 약 3일 정도 삽질을 한 게 욕심내서 APIView로 하나하나 만들어 보려다 코드가 점점 더러워져서 Viewset으로 바꾸어 만들었습니다. 2일 동안 만든 코드가 Viewset으로 바꾸니 하루만에 다 고칠 수 있을 정도로 Viewset는 편리했습니다. 그리고 나머지 customizing이 필요한 부분만 APIView로 커버했습니다.

가장 재밌으면서 오래 걸렸던 부분은 Django ORM을 이용해서 total asset을 구하는 부분이였는데 transaction_type이 Buy와 Sell 둘로 나누어져 있어 이걸 Case를 이용해 Buy는 +로 Sell은 -로 새로운 field를 만들어주고, 합쳐주는 쿼리문을 만든 것이었습니다. 처음에는 어렵게 느껴졌지만 계속 새로고침하면서 에러를 통해 고쳐나가니 빠르게 배울 수 있었습니다. 

이 쿼리문 하나 만드는데 Django Document와 블로그 글을 통해 1시간 넘게 걸린 것 같은데 아래의 transaction을 POST받을 때 자산에 음수가 나오지 않도록 하는 것을 만드는데는 10분도 안 걸린 것 같습니다.ㅋㅋ

이제 이걸 배포하고 React를 이용해 Front-end를 만들고 이어주는 것만 남았는데 백엔드 만드는데만 하루에 2~3시간씩 약 8일이 걸렸는데 대략 끝내기까지는 예상한 대로 2주는 더 걸리지 않을까 생각이 듭니다.

Github 주소: https://github.com/qhqnf/asset-dashboard

Function Based View를 사용하고 싶으면 @api_view

Class Based View 사용하고 싶으면 APIView, Generics.~~APIView, Viewset 중 하나

APIView는 View(Rest Framework에 있는게 아닌 Django에 있는 것)를 상속받긴 하지만 거의 백지상태. 안에 만들고 싶은 Http method를 골라서 만들어주면 됨. (ex. get, post, put, delete ...)

Generics.~~APIView와 APIView 사이에 GenericAPIView가 있긴 한데 둘을 이어주는 징검다리 느낌. GenericAPIView를 써본 적은 없음. 이제 ListAPIView, ListCreateAPIView, DestroyAPIView 등등이 있는데 단어 하나가 붙을 때마다 그 Mixin같이 따라 온 거라 보면 됨. (ex. ListAPIView는 APIView에 ListModelMixin이 같이 와서 List Method를 이미 어느정도 만들어 놓음)

Generics에 있는 View들은 get, post, put, delete method를 잘 가공해서 List( or Retrieve), Create, Update, Destory로 만들어 놓음. 그래서 get, post method를 보면 그냥 가공해 놓음 List( or Retrieve), Create method를 부르기만 함.

Viewset과 APIView 사이에도 GenreicViewset이 있긴 한데 이것또한 징검다리 같은 느낌. Viewset들은 위의 Mixin들은 많이 넣어서 더 편리하게 만들어 놓음. ModelViewSet은 Mixin들을 모두 넣어 놓았고, ReadOnlyModelViewSet은 get만 가지도록 List와 Retrieve Mixin만 가져옴.

참고 문헌: http://www.cdrf.co/