우테코 3주차 - 2주차 피드백 검토

벌써 우테코 3주차에 접어들었다.

 

2주차 피드백을 검토해보자

---

1. README.md 작성 관련

- 이 프로젝트가 어떤 프로젝트인지

- 어떤 기능을 담고 있는지

- 마크다운 문서 문법을 학습하고 적용할 필요가 있음

 

2. 기능목록 

- 클래스 설계/구현, 함수 설계처럼 너무 상세하지 않게 => 언제든 변경이 가능하므로

- 예외적인 상황도 정리

- 기능구현을 하며 변경이 가능하므로 처음부터 완벽히 작성하기보다 계속 업데이트

=> 죽은 문서가 아닌 살아있는 문서를 만들자

 

3. 값 하드코딩x

=> 하드코딩 : 데이터를 코드 내부에 직접 입력하는 것

: 상수(static final)을 만들고 이름을 부여해 변수의 역할을 드러내기

 

 

4. 구현 순서 = 코딩 컨벤션

클래스 구현 순서 :  상수 >  멤버 변수 >  생성자  > 메서드 순으로 

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

 

5. 변수 이름에 자료형 사용x

변수 이름에 자료형, 자료 구조 등을 사용하지 마라.

String carNameList = Console.readLine(); String[] arrayString = carNameList.split(",");

 

6. 함수의 기능 개별화

- 한가지 기능만 담당하도록

- 안내문구 출력 / 사용자입력 / 유효값 검증의 기능을 분리하기

-함수의 길이를 15라인을 넘어가지 않도록 구현

 

 

7. 테스트

 

7-1) 나의 경험 녹여내기

- 테스트는 나의 코드 피드백 + 학습도구로도 활용가능

- 테스트를 통해 어떤 유용함을 느꼈는지 기록하기

 

7-2) 처음부터 큰 단위의 테스트 X

- 테스트의 목적 : 내 코드의 피드백

- 문제를 작게 나누고 핵심기능부터 테스트 구현

 

ex)

 

큰 단위의 테스트

• 자동차경주를 시작해서 사용자가 이름, 진행 횟수를 입력하면, 게임을 진행한 후 그 결과를 알려준다.

 

작은 단위의 테스트

• 무작위 값이 4 이상이면 자동차가 전진한다.
• 무작위 값이 3 이하이면 자동차가 전진하지 않는다.

---

 

느낀 점

 

- README.md를 죽은 문서로 놔두었다는 생각

: 기능 목록은 처음 작성하고 나서 거의 업데이트를 하지 않았다. 기능목록을 업데이트하는 순간 처음부터 잘못된 설계를 했다는 느낌을 받았고 또 그런 인상을 줄 것 같다는 생각 때문이었다. 그러나, 변화는 자연스럽고 오히려 초기 설계에 코드를 맞추기보다 코드에 따라 기능구현 목록이 살아움직여야 한다는 생각이 들었다.

 

- 변수 이름

: 지난 2주차에는 1주차 피드백을 기반으로 변수가 그 기능을 잘 드러내도록 노력했다. 그래서 CarList와 같은 클래스 명과 변수명을 사용했다. 그러나, 자료형 자체를 변수이름에 사용하는 것은 좋지 않은 습관임을 알게되었다.

 

- 함수기능의 개별화

: 3주차 추가 요구사안에도 추가된 부분이다. 하나의 덩어리를 여러 레고조각으로 쪼개고 분리하는 시각이 필요할 것 같다.

 

- TDD

: 지난 주 미션부터 테스트 작성에 대한 부분이 강조되면서, 어떻게 해야 좋은 테스트 작성을 할 수 있을지 고민중이다. 지난 우테코 포비님께서 강의한 TDD작성 요령을 참고할 생각이다.