리펙토링시 체크할 사항들

“커밋을 한 이상 더이상 내 코드가 아니오.”

사용되지 않는 필드(column)가 있을수 있습니다. 지웁시다.

데이터베이스의 field, column 중에 이용되지 않는 것이 있을 수 있습니다. 이용되지 않는 데이터는 지웁니다.

최대한 메서드로 만듭시다.

아무리 작은 일이라고 해도 메서드로 만들어서 이용하는 것과 안하는 것의 차이는 아주 큽니다. 나만 보는 코드가 아니라는 것을 명심합시다.

합치면 좋은 함수가 있을 것입니다.

같은 일을 하지만 인자의 종류, 인자의 갯수 등 사소한 차이로 함수의 갯수가 많아질 수 있습니다. 정말 사소한 차이로 복수개의 함수로 정의되어있을 필요가 있는지 고민해봅니다.

혹은 나누어서 관리하는게 편한 함수가 있을수도 있습니다.

무리하게 하나의 함수가 많은 종류의 인자를 받게 되면 if문이 많아질 수 있습니다. 혹은 인자의 종류에 따라 사소한 차이일 뿐이라고 생각했던 것들이 유지관리할 때는 큰 불편함을 야기할 수도 있습니다. 유지 관리가 힘들다면 같은 일을 하는 함수일지라도 인자가 다르다면 분리시키는 것도 좋을 수 있습니다.

안쓰는 라이브러리는 지웁니다.

개발 도중에 여러 시도를 해볼텐데 그 과정에서 테스트해보고 나중에는 쓰지 않는 라이브러리들이 많을 것입니다. 체크하여 지워줍니다.

그리고 프로덕션 환경에서 쓸 것이라고 확신이 들지 않는다면 개발 모드로 모듈,라이브러리를 다운로드해서 이용하는 습관을 들입시다.

초기에 정한 디자인 패턴을 잘 따르고 있는지 확인합니다.

개발 초기에 설계한 코드 구현 방식이 있을 것입니다. 보통 “디자인 패턴”이라고 하죠. 디자인 패턴을 손수 만들어서 하는 일은 거의 없을것입니다. 어떤 책을 따라하거나 잘 정리된 글을 따라서 하는 것이 대부분입니다. 이러한 글들을 다시 한번 천천히 읽고 리펙토링을 시작합시다.

계층간 책임을 명확히 지키는지 확인합니다.

디자인 패턴으로 정한 계층간의 책임 분리를 잘 따르고 있는지 확인합니다. 계층 간의 책임이 애매해지거나 책임에 없는 일을 하게 된다면 다른 개발자가 코드를 읽기가 힘들어집니다.

github commit 도 비슷한 내용이면 하나로 합칩시다.

개발 도중에 커밋을 디테일하게 하다보면 커밋이 불필요하게 많아질 수 있습니다. 같은 내용이라면 하나의 커밋으로 rebase 하는 것이 좋습니다.

불필요한 주석은 지웁시다. 괜히 동료에게 혼란을 줄 수 있습니다.

애매하여 주석처리해놓은 함수, 변수는 모두 지웁니다. 다른 개발자에게 혼란을 줄 수 있습니다.

함수명, 변수명을 정리합시다.

다른 개발자가 보기에 함수의 이름으로 함수가 하는 일을 추측할 수 있을 지 파악합니다. 최대한으로 친절하게 함수 이름을 정합시다.

조건 논리 / 분기를 깔끔히 해봅시다.

개발 도중에 if, while문 등을 대충 만들어 놓고 넘어갈 때가 꽤 있습니다. 조건문이/분기가 깔끔하지 않으면 함수가 보기 어려워질 수 있습니다. 각 언어의 권장 방식대로 정리합시다.

함수 인자들을 같은 형식/모양으로 보내줍시다.

인자 전달 방식이 함수마다 다르면 다른 개발자가 보기에 너무나 힘듭니다. 최대한 비슷한 방식으로 전달하도록 합시다. DTO로 감싸서 하나로 보내줄거면 되도록 다른 함수들도 DTO로 하나로 감싸서 보내주고, DTO로 감싸지 않고 function1(arg1, arg2, arg3)처럼 하나하나 보내줄거면 대부분의 함수에서 이렇게 해야 남이 보기 편합니다.