ProgrammingStudy

책 - 클린코드 (5장/형식 맞추기, 6장/객체와 자료 구조)

, , , ,

5장 - 형식 맞추기

소감

5장에서는 형식 맞추기로 소개가 되어있지만 가독성 높은 코드를 작성하기 위한 컨벤션 맞추기 라고 봐도 될거 같습니다. 적절한 행의 길이를 맞추고, 변수들끼리 모아두고, 빈 행으로 개념을 분리 하는 등의 방법을 소개하면서 코드를 가독성 높게 만드는 방법을 알려주고 있습니다.

형식이란건 사실 개발자 개개인에 따라 취향이 확고하게 나뉠 수 있다고 생각이 되는데요
아래 코드를 보았을때 저는 1의 형식을 선호하지만 가끔씩 2의 형식을 더 선호하는 사람을 보았습니다.

1
2
3
4
5
6
7
8
9
10
// (1)
if(true) {
    ...
}

// (2)
if(true) 
{
    ...
}

기능상에 문제는 없지만 이런 취향의 차이가 코드에 반영되면 협업을 할때 생산성에 영향이 있을거 같아서 협업을 할때는 컨벤션을 정해두고 그걸 맞춰서 작성하면 좋을거 같습니다.

제가 일하는 회사에서는 따로 컨벤션을 정해두고 사용하고 있지는 않는데요 일반적으로 다 비슷한 형태의 형식으로 작업이 이뤄지지만 공통의 컨벤션을 적용할 수 있는 방법이 있다면(ex. linter 같은) 좀더 효율성이 좋아지지 않을까 생각을 해보았습니다.

 
 

강의 내용

포맷팅이 중요한 이유

  • 가독성에 필수적이다

클린코드 포맷팅

  • 적절한 길이 유지
  • 밀접한 개념은 가까이

Java Class Declarations

  • 클래스 선언 순서 (public —> private 순서)

Team Coding Convention

 
 
 

6장 - 객체와 자료 구조

소감

클래스를 만들때 객체지향적으로 생각해서 필드와 클래스를 만드는데 단순히 조회와 설정 함수만 가지고 있는 클래스를 많이 만들었던거 같습니다. 객체지향의 개념은 알고있지만 그걸 제대로 구현하는것은 쉽지 않다는 생각을 했습니다. 책에 나오는 디미터의 법칙과, 기차 충돌에 대한 내용을 읽으면서 ‘나도 저런 코드 작성한적이 있었던거 같은데?’라는 생각도 많이 했습니다. 객체와 자료구조를 구분해서 작성해야하는데 거의 대부분 자료 전달 객체인 형태로(DTO)로 많이 구현했던거 같았습니다. private 필드와 public getter,setter를 습관적으로 만들면서, 기차충돌 형태의 코드가 발생하게끔 만들었던거 같았습니다.

강의내용

자료구조 vs 객체

  • 자료구조 : 데이터 그 자체(조회와 설정만)
  • 객체 : 비지니스 로직 관련(자료는 숨기고, 추상화된 함수만)

객체 - 디미터 법칙

  • 클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야한다.

    • 클래스C
    • 자신이 생성한 객체
    • 자신의 인수로 넘어온 객체
    • C 인스턴스 변수에 저장된 객체

  • 기차 충돌

DTO

  • 로직없이 필드만 갖는다
  • getter/setter

Active Record

  • Database row를 객체에 맵핑하는 패턴
  • Active Record vs Data Mapper
    • Active Record : row + db 접근을 포함 (ROR)
    • Data Mapper : row / db 접근 분리 (Hibernate)
공유하기