개인 프로젝트 마지막 날! (22.09.23 TIL)

 오늘은 최종적으로 본인이 만든 프로그램을 시연하며 코드 리뷰 및 프로젝트 피드백을 받는 날이었다. 최종적, 이라고 썼지만 아직 기능이 정말 구현되지 않은 부분이 있어서 오늘 밤까지 작업한 후 완성할 예정이다. 

 그리고 시연회를 하면서 동기들과 함께 홀맨님의 코드 리뷰를 받았는데 말씀해주신 것들 다 필요한 내용이지만 그 중에서도 제~일 내가 못 지키고 있는 것들을 정리해 보았다.

• 파일 매니저를 각각 개별적으로 만들기 보다는, 저장소라는 중간 매개체를 만들어서 추후 데이터를 불러오는 방식이 바뀐다고 해도 (SQL을 통해 DB를 저장하든, 파일로 불러오든) 코드가 돌아가는 것에는 상관없게 만드는 것.

=> 나의 문제점 중 하나는 추후 발생할 일, 즉 경우의 수를 생각하지 않는다는 것이다. 한 방법을 배우면 그게 최선인 것으로 생각해버리고 마는 습관이 있다. 먼저 코드를 일단 돌아가게만 해놓고 리팩토링을 할 때 더 나은 방법이 무엇이 있을지, 이런 방식으로 하면 어떤 문제가 발생할지 스스로 고민해보는 습관을 가지자... 머리로는 인지가 잘 안 되기 때문에 생각으로만 하지 말고 먼저 손으로 써보자!

• 테스트 코드를 짤 때 중복되는 값을 사용해야 한다면 아예 맨 위에 상수로 빼버리자. 만약 한 테스트에서만 사용된다면 그 테스트 바로 위에다 상수를 선언해놓자. 테스트 코드에서도 중복을 줄이자.

=> 이건 생각지도 못한 문제였는데, 테스트 코드도 하나의 인수인계서이다. 내가 아닌 다른 누군가가 봤을 때, 이 테스트 코드만 보고서도 이해가 갈 것 인지를 생각해봐야 한다.

• 한 테스트 안에 여러 기능을 테스트 하는 것은 가독성이 떨어진다. 각 기능이 있는 것들은 개별 테스트를 돌려서 실제 내가 기대하는 값이 나오는지 확인하자.

=> 동기 분의 코드 리뷰중에 홀맨님이 말씀하신 조언인데 내 테스트 코드에도 이런 것들이 많아서 적어놓았다. 예를 들어 사칙연산을 해야 하는 프로그램을 만들기 위해서 테스트 코드를 짤 때, 더하기 기능을 하는 함수 테스트에는 더하기 테스트만 해야 하는데 다 관련이 있다고 생각하고 사칙연산을 한 테스트 코드 안에 해버리면 안 된다. 테스트 코드도 관심사의 분리를 하자.

• 리팩터링의 전제 조건은 테스트 코드이다. 우리는 코드가 정상 작동한다는 확신을 가진 상태에서 코드를 리팩터링 해야 하고, 확실하지 않은 상황에서는 변경하면 안 된다.

=> 그렇기 때문에 리팩토링을 하기 위해선 먼저 테스트 코드를 짜야한다! 리팩터링을 하고 싶다? 내 코드가 이상해 보인다? 테스트 코드를 먼저 안 해서 그렇다!!!

• 메서드를 아무렇게나 생성하지 말고 순서대로! 가독성 있게 ! 만들자.

=> 이거는 원래 지키고 있던 내용이지만 다시 상기하기 위해.. 메서드를 중간중간 필요할 때 만들다 보면 런타임 흐름과 상관없게 메서드 순서가 뒤죽박죽 될 때가 있다. 반드시! 다른 누군가 내 코드를 볼 수 있다는 걸 명심하고 코드 정리를 잘해놓자.