[우테코] 1주 차 백엔드 피드백

이름을 통해 의도를 드러내라

변수 이름, 함수(메서드) 이름, 클래스 이름을 짓는데 시간을 투자하자.
이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내기 위해 노력하라.
연속된 숫자(a1, a2, ...), 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.

축약하지 마라

의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.

누구나 클래스, 메서드 또는 변수의 이름을 줄이려는 유횩에 곧잘 빠지곤 한다. 그런 유혹을 뿌리쳐라.
축약은 혼란을 야기하며, 더 큰 문제를 숨기는 경향이 있다.

클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제하자.
클래스 이름이 Order라면 shipOrder라고 메서드 이름을 지을 필요가 없다.
짧게 ship()이라고 하면 클라이언트에서는 order.ship()라고 호출하며, 간결한 호출의 표현이 된다.

: 객체 지향 생활 체조 원칙 5: 줄여쓰지 않는다(축약 금지)

공백도 코딩 컨벤션이다

if, for, while문 사이의 공백도 코딩 컨벤션이다.

공백 라인을 의미 있게 사용해라

공백 라인을 의미 있게 사용하는 것이 좋아 보이며, 문맥을 분리하는 부분에 사용하는 것이 좋다.
과도한 공백은 다른 개발자에게 의문을 줄 수 있다.

반복하지 마라

중복은 소프트웨어에서 모든 악의 근원이다.

space vs tab 혼용

들여쓰기에 space와 tab을 혼용하지 않는다. 둘 중 하나만 사용한다.
확신이 서지 않으면 pull request를 보낸 후 들여쓰기가 잘 되어 있는지 확인하는 습관을 들인다.

의미 없는 주석을 달지 않는다

변수 이름, 함수(메서드) 이름을 통해 어떤 의도인지가 드러난다면 굳이 주석을 달지 않는다.
모든 변수와 함수에 주석을 달기보다 가능하면 이름을 통해 의도를 드러내고, 의도를 드러내기 힘든 경우 주석을 다는 연습을 한다.

커밋 메시지를 의미 있게 작성하라

커밋 메시지에 해당 커밋에서 작업한 내용에 대한 이해가 가능하도록 작성한다.

기능 목록을 업데이트하라

README.md 파일에 작성하는 기능 목록은 기능 구현을 하면서 변경될 수 있다. 시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 가지기보다 기능을 구현하면서 문서를 계속 업데이트한다. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.

기능 목록을 재검토하라

기능 목록을 클래스 설계와 구현, 함수(메서드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다. 클래스 이름, 함수(메서드) 시그니처와 반환값은 언제든지 변경될 수 있기 때문이다.

너무 세세한 부분까지 정리하기보다 구현해야 할 기능 목록을 정리하는 데 집중한다.

정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다.
특히 예외 상황은 시작단계에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해 나간다.

README.md를 상세히 작성하라

미션 저장소의 README.md는 소스코드에 앞서 해당 프로젝트가 어떠한 프로젝트인지 마크다운으로 작성하여 소개하는 문서이다. 해당 프로젝트가 어떠한 프로젝트이며, 어떤 기능을 담고 있는지 기술하기 위해서 마크다운문법을 검색해서 학습해보고 적용해 본다.

IDE의 코드 자동 정렬 기능을 활용해라

IDE의 코드 자동 정렬 기능을 사용하면 더 깔끔한 코드를 볼 수 있다.

• IntelliJ IDEA : option + + command + L,
• Eclipse : control + command + F

매직 넘버를 사용하지 마라

매직 넘버는 의미를 나타낼 수 있는 상수 (static final)로 치환하여 코드의 가독성을 높인다.

구현 순서도 코딩 컨벤션이다

클래스는 상수, 멤버 변수, 생성자, 메서드 순으로 작성한다.

class A {
  상수(static final) 또는 클래스 변수
  
  인스턴스 변수
  
  생성자
  
  메서드
}