[우아한테크코스/프리코스] 1주차 백엔드 피드백

우아한테크코스의 프리코스 1주차 미션 제출 후 받은 공통 피드백 내용 중 나에게 도움이 된 피드백 내용과 그에 대한 생각, 또 해당 피드백을 코드에 어떻게 적용하였는지 작성하였다. 

 

축약하지 마라

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

누구나 실은 클래스, 메서드, 또는 변수의 이름을 줄이려는 유혹에 곧잘 빠지곤 한다. 축약은 혼란을 야기하며, 더 큰 문제를 숨기는 경향이 있다. 클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제하자.

클래스 이름이 Order라면 shipOrder라고 메서드 이름을 지을 필요가 없다. 짧게 ship()이라고 하면 클라이언트에서는 order.ship()라고 호출하며, 간결한 호출의 표현이 된다. - 객체 지향 생활 체조 원칙 5: 줄여쓰지 않는다(축약 금지)

 

너무 감사한 피드백이었다. 지금까지 나는 클래스, 함수 이름을 명확히 지어라, 축약하지 말라는 의미를 다르게 이해했던 것 같다. 오히려 문맥을 중복하는 이름을 사용하고 있었다. 앞으로는 클래스 이름을 메서드 이름에 중복하여 넣지 말아야겠다. 주의하자.

 

 

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

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

 

기능 목록을 재검토하라

기능 목록을 클래스 설계와 구현, 함수(메서드) 설계화 구현과 같이너무 상세하게 작성하지 않는다. 클래스 이름, 함수(메서드) 시그니처와 반환값은 언제든지 변경될 수 있기 때문이다. 너무 세세한 부분까지 정리하기보다 구현해야 할 기능 목록을 정리하는 데 집중한다. 정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다. 특히 예외 상황은 시작 단계에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해나간다. 

 

너무 찔리는 피드백이었다. 그동안 나는 기능 목록을 세세하게 작성하는게 더 좋겠지? 라는 생각으로 작성해왔는데 오히려 내가 어떤 기능을 구현해야하는지, 예외 상황은 어떤 것들을 고려해야할 지 구현할 기능들을 빠짐없이 모두 구현하였는 지 확인 할 수 있는 용도로 작성하는 방향으로 변경해야겠다고 생각하게 되었다. 

 

피드백을 반영하여 "2주차 미션: 자동차 경주 게임"의 기능 목록을 수정하였다. 내용적으로 변경된 부분은 거의 없지만 클래스 별로 기능을 분리하던 방식에서 입력, 자동차 경주 시스템, 출력으로 기능을 분리하는 방식으로 변경하였다. 그저 기능 목록을 나열하는 것보다는 이렇게 구분하는 것이 제가 보기에 편해서 이렇게 작성하였다. 보기 편한게 쨩..

2주차 미션 - 자동차 경주 게임

 

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

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

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

 

클래스 변수도 구분한다는 것에 주의하자.

 

여기서 더 덧붙이자면

1. 메서드는 public -> private 순으로 작성하며, public에서 사용한 메서드를 그 가까이에 둔다. 

2. "공백 라인을 의미있게 사용하자"의 피드백을 적용하면 공백을 통해 상수, 클래스 변수, 인스턴스 변수를 구분할 수 있다.