왜 듣게 되었나?

나는 몇년동안 개발자로 일하면서도 그렇게 제대로된 코드리뷰를 받아본 적이 없다
좋은 코드를 만들기 위해 여러 서적도 읽고 스터디도하고 적용도 해보왔지만 상황이 다르고
예제나 설명만으로는 내가 정말 맞게 하고 있는지
내가 놓치고 있는 부분이 있는지 항상 의문점이 있었다
그리고 두려움도 있었다 신입시절 사수분이 항상 코드를 작성하면 불러다가
한숨 푹푹 쉬면서 코드에 대한 질타와 욕을 먹은 기억이 있다
나중에 그건 정상적인 코드리뷰가 아니란 것을 알았지만
그것 때문에 누군가에게 코드를 보여준다는 것에 대한 두려움이 생겼다...
하지만 이런 일(코드 리뷰에 대한 두려움)은 구글에 입사한 사람에게도 자주 겪는 일이라고 한다
그래서 코드숨 스프링과정을 듣게 되었다!

교차 검증이 안되기 때문에 제대로 가고 있는지 알 수가 없다...

문제점

1. 초반에 습관적으로 너무 급하게 하려고 하다보니까 삽질을 많이 한것 같다 침착하게 하나씩 진행하자.
2. 하나의 패턴을 만들면 그 패턴에서 벗어나지 않으려는 습관이 있는것 같다...

배운점

1. git을 사용한 코드리뷰 프로세스

• 이전 직장에서는 SVN을 사용했고 git을 개인적으로 쓰고는 있지만 혼자서 그냥 자신이 쓰던 기능만 사용했기 때문에 pull request 프로세스에 관해 익숙치 않았다.

2. 기본적인 코드 컨벤션

• IDE에 저장할때 자동정렬 해주는 기능이 있는것을 처음 알았다...
• POSIX 표준으로 코드 마지막줄 개행 해야한다는 것

3. 책임의 분리

• 책에서 책임의 분리라는 말을 읽기는 했지만 구체적으로 뭘 어떻게 해야하는지 인지를 못했었던것 같다.
• 사실 로직의 코드수가 별로 길지 않으면 여러가지 책임을 한번에 지게하는 관성적인 습관이 있었다
• 코드에 변경이 될 이유가 한가지만 있어야한다.
  

4. 메서드로 분리해서 변경에 영향을 적게 주는 건 좋은 일이지만 메서드명이 적절하지 않은경우 오히려 알아보기 힘들어질수 있다.
   

개선할 점

1. git의 명령어가 어떤 동작을 하는지 자세히 알고 사용해야 할 것같다...
2. 해당 객체 메서드에게 너무 많은 책임이 지어져 있는지 주의하자.
3. 메서드명을 좀 고민하고 정하자.
4. 위의 경험을 살려 자체적으로 한번더 코드를 보고 고민하고 수정하는 시간을 가져도 좋을것 같다.

그 외

• 윈도우에서 gradlew 로 서버를 실행하면 한글이 깨진다 ios 는 기본 인코딩이 UTF-8이나 윈도우는 아니므로 컴파일 및 런타임 인코딩설정이 필요하다.