읽기쉬운 코드 만들기

SoftWare 의 3대가치

• 제대로 동작하는 것
• 변경에 유연해야하는 것
• 쉽게 코드를 읽을 수 있어야 하는 것

본인의 명확한 기준이 필요한 이유

• 일관성 있는 코드 & 코드리뷰 작성
• 코드 및 의견에 대한 명확한 근거제시 -> Why?
• 자신이 작성한 코드의 근거가 없을 시 다른의견에 흽쓸려 지나가게된다.

기억한 Context가 많은 코드는 읽기 어렵다.

• 코드 한줄을 이해하기위해 가지고있어야 하는 정보가 많은 코드는 읽기 어렵다. (심지어 미래의 내가 읽더라도!)
• 이미 읽엇던 코드를 다시 읽게되는 상황이 발생.

• 1. 나중에 사용할 변수를 미리선언하지말자.

  • 가변 변수를 사용 할 경우 흐름에 따라 알아야할 값이 달라진다.
  • 해당 변수가 설명적(직관적)이지 않을경우 변수의 주기를 알아야함.
  • 변수에서 수정이 발생할시 모든메소드에 변경이 전파 될 수 있다.
  • 해당변수를 변경하는 모든메소드를 같이고려해야 한다.
  • 가능한 사용할곳과 변수를 생성해라.
  • 변수가 활동하는 Scope 를 작게하자.(블록단위 등)

  2. 메소드크기가 커지는것을 주의하자.

  • 크기가 커질수록 책임이 많아지고 기억해야할것이 많아짐.

요약

• 자신의 코드에 대한 문맥과 자기만의 기준을 만들어야한다.
• 일관성 있는 코드를 작성하는것이 중요. (피드백을 받기 쉬워진다)
• 면접에 큰 도움이 된다.

위에서 아래로 설명하는 코드를 작성.

• 잘 작성된 코드는 잘 작성된 글과 비슷하다.

• 1. 흐름대로 읽을수 있는(잘 읽히는) 코드 작성.

  • 중요한 코드일수록 문제가 크리티컬 해짐.
  • 비슷한 추상화 수준 , 적당히 추상화된 메소드 , 위임
  • 코드와 한글의 싱크로율이 높을수록 좋다.

  2. 예상한대로 흘러가는 코드 작성.

부수효과 없는 메소드 만들기

• 메소드가 설명하고 있는 행위와 다른 무언가로 행위 추가.
• 위치와 흐름을 예측하지못하는곳에서 발생시 버그발생이 쉬워짐.

관심사의 분리

• 복잡한 APP을 한번에 개발하기엔 매우어려움.
• 문제를 보다 작은단위로 해결해가는 기법.
• 캡슐화를 통한 낮은 결합도 (객체끼리의 일은 관심이 없어야 함)

Nullable 한 타입은 읽기 어렵다.

• Nullable 한 타입은 문맥 을 숨긴다.
• 행동에서 Null을 체크하는것을 강요하게 됌.
• Null을 사용할경우 최대한 다른사람들에게 알리려는 도구가 필요.
• 매직넘버, 생성자, 숨겨진도메인 관련해서도 문맥을 숨기게 된다.

생각해볼 것

• NULL을 허용이 가능해야할때?
• DB 격리수준, 트랜잭션 전파수준, Index