개발 TIP

 

 

• 리팩터링 시 큰 틀의 구조부터 천천히 바꿔나가야 한다. 구조를 변경하다 보면 그 안에 코드를 리팩터링 하게 되는 경우가 있는데, 목표에서 멀어질 가능성이 있다. 내부 코드의 리팩터링 요소가 보인 다하더라도 구조를 먼저 리팩터링 하기로 했으면 구조만 먼저  리팩터링 하자. 추후 내부 코드를 리팩터링 해도 늦지 않다. 구조 변경 시 내부 코드 때문에 초기 계획했던 구조 리팩터링에 영향을 미치기 시작하면 끝도 없다.
  
  
• 널리 알려진 포트나 HTTP 상태 코드를 상수로 코드에 넣어놓고 다른 개발자가 쉽게 이해할 것이라는 생각은 안된다. 작은 리소스인 변수로 코드 가독성을 크게 향상 시킬 수 있는 방법이다.
  
  
• 메소드 안에서 하는 행동의 레벨이 다르다고 느낄 수 있다. 특정한 행동을 목표로 행하지만 그 행동에 대한 부가적인 계산, 설정이 필요한 경우가 존재하는데 이걸 레벨이 다르다라고 표현할 수 있다. 레벨이 다를 때 해당 부가적인 행동을 메서드로 따로 분리하는 것이 좋다.
• 객체와 값을 지칭하는 별도의 용어가 있는데, 요즘에는 엔티티라는 말을 사용한다. entity는 객체를 식별하게 해주는 식별자를 지닌 전통적인 의미의 객체를 가리는 용어이다.
• HTTP 요청 시  같은 요청의 로그에 모두 같은 식별자(UUID.. 트랜잭션 ID)를 자동으로 남기는 방법은 logback-mdc를 참고
• 로그에 대해서 요즘 깊이 고민하고 있는데, 오류 및 서비스 장애, 민원 발생 시 로그에 중요성을 깨닫고 있는데, 여러가지 모니터링 툴을 도입할 수 있다면 베스트지만, 그렇지 못하는 경우가 상당히 많다. 로그는 최대한 자세하게 로그를 파일로 세세하게 쪼개서 backup또한 진행하는 것이 좋고 로그 관리에대한 적절한 정책이 필요하다.
• 변하는 것과 변하지않는것 분리하여 모듈화하는 판단.