그냥 코드 리뷰를 받으면서 느꼈던 점을 생각하던 중에 문뜩 생각난 부분들을 정리해봤다
자신의 코드를 제일 잘 아는 사람은 자신이다
물론 기존의 레포를 잘 알고 있는 사람이 리뷰를 하게 된다면 기능상에 대해서는
코드 리뷰 자체는 다방면으로 할 수 있지만, 주로 코드를 작성하는 방법론에 대한 이야기가 많은 것 같다
코드 리뷰의 한계보다는 코드 리뷰의 전제에 대한 이야기다
리뷰를 하는 사람은 해당 브랜치를 따서 테스트를 하기 어렵기 때문에
기능의 완벽한 구현보다는 코드 부분을 주로 살피게 될 것이고,
메소드를 제대로 사용하지 않는 수준 이외의 부분을 점검하지는 않을 것이다
그렇기 때문에 PR에 대한 책임감을 가져야 한다
즉 기능적으로 문제가 없다는 확신이 들었을 때 PR과 코드 리뷰 등으로 다른 사람의 손에 자신의 코드를 넘겨야 한다
모듈화에 대한 고민
절차지향적으로 하나의 프로세스가 쪼개졌을 때, 리팩토링을 고민하게 되고, 실제로 기능을 더하기 위해 시작했다가 복잡한 코드를 보고 모듈화를 하게 되는 경우가 있었다
이 과정에서 고민이 됐던 부분은 다음과 같다
- 하나의 함수에 함수명에 부합하지 않는 과정이 있을 때 어떻게 할지
- 함수가 어떤 기능을 수행하는지에 대해서 명확하게 알 수 없을 때
- 반복되는 부분이 명확하게 존재하고 이를 인지할 때
본인은 최대한 모듈화를 지향하는 편인데, 모듈화를 어떻게 할지, 어디에 할지에 대한 고민도 생겼던 것 같다
만약에 DB 이외의 간단하고 반복적인 로직을 처리한다면 utils.py 이런 부분에 빼는 것도 하나의 방법이라고 생각을 했고,
코드를 짜는 것 뿐만 아니라 코드를 어디에 위치할지에 대해서도 고민해야 한다는 것을 느꼈다
(전체적인 코드 아키텍처와 관련)
그외 파이썬이나 개발에 대한 기본적인 지식
클래스 내부에서 사용하는 메소드에 대해서는 underscore(_) 를 사용한다는 점
변수명에 대해서는 끝없이 고민해야 한다는 점 (비즈니스 로직 뿐만 아니라 다른 사람이 자신의 코드를 볼 때를 생각하자)
