우테코 2주차 - 1주차 공통 피드백 검토

우테코 프리코스에서는 각 주차별 미션공지와 함께

작성 코드에 대한 공통피드백을 주신다.

 

이 부분에서 미션의 의도를 파악할 수 있고

앞으로 신경써서 개선해야할 포인트들을 알아낼 수 있으리라 판단했다.

 

이 피드백을 바탕으로 다음 미션 코드를 개선할 수 있고,

내가 어떤 점을 간과하고 있었는지 검토해보자

 

---

1. 요구사항을 정확히 준수한다.

 

- 1번부터 조금 찔렸다. 시험기간이라 기능 구현에만 급급했던 게 사실이라 코드 컨벤션이나 depth와 같은 프로그래밍 요구사안을 꼼꼼히 확인하지 못했던 것이 마음에 걸린다.

 

2. 커밋 메시지를 의미있게 작성한다.

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

 

내가 작성한 커밋 메시지를 다시한번 검토해보았다.

 

문제가 확연했다. 

 

- 함수 : 어떤 기능인지를 모호한 부분이 많았다.

: 추상적인 메시지로 인해 결국 변경사안을 확인해야 파악이 가능한 경우가 많았다.

 

- 어떤 적합성을 검토하는 것인지 명시하자

ex) feat : check User's input valid or not의 경우

인풋 데이터 적합성 검사를 하는 기능인것 같다.

정확히 어떤 부분을 예외처리하고 검사한 건지 드러나 있지가 않다.

 

- 되도록 scope를 같이 명시해주자

: 영향을 주고 받는 scope를 되도록 표기해주는 것이 좋을 것 같다

 

3. git을 통해 관리할 자원에 대해서도 고려한다

 

.class 파일은 java 코드가 있으면 생성할 수 있다. 따라서 .class 파일은 굳이 git을 통해 관리하지 않아도 된다.
IntelliJ IDEA의 .idea  폴더, Eclipse의 .metadata 폴더 또한 개발 도구가 자동으로 생성하는 폴더이기 때문에 굳이 git으로 관리하지 않아도 된다.

 

앞으로 git에 코드를 추가할 때는 git을 통해 관리할 필요가 있는지를 고려해볼 것을 추천한다.

 

=>더 알아보니 실제로 git에서는 gitignore을 통해 자동으로 push를 무시하는 기능이 있었고, 무시할 파일들을 사용자가 확장자를 추가하거나 뺄 수도 있었다.

 

참고:

https://studyingpingu.tistory.com/30

[git] .gitignore 깃허브에 푸쉬하지 말아야하는 것들에 대해

 

 

4. PR을 한 번 작성했다면 닫지 말고 추가 커밋을 한다

PR을 이미 한 번 보냈다면, 새로운 PR을 생성할 필요가 없다. 수정이 필요하다면 추가 커밋을 하면 자동으로 반영된다. 단, 미션 제출 기간 이후에는 추가 커밋을 하지 않는다.

 

=> PR의 개념을 제대로 이해하지 못해서 발생한 실수

=> git강의를 들은 지금은 커밋만으로도 pull한 곳에도 갱신된다는 사실을 알고 있다.

 

 

5. 이름을 통해 의도를 드러낸다

의미 있는 이름짓기.... 사실 1주차 미션에서 가장 힘든 부분이었다.

 

알고리즘 문제를 풀 때에는 대부분 단항변수이름을 사용했다.

그게 사용하기 편하고, 무엇보다 나만 알아보면 되니까

그러나, 협업 프로젝트를 할 때는 혼자 하는 일이 아니라는 걸 체감하고 있다.

 

즉, 내가 아닌 타인이 이름을 통해 이 메소드의 의도를 파악할 수 있어야 했다.

조금 이름이 길어지더라도 기능을 충분히 담을 수 있는 이름 짓기가 필요하다는 사실을 체감했다.

 

 

6. 컨벤션 관련 피드백

 

- 공백도 코딩 컨벤션이다

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

 

-  공백 라인을 의미 있게 사용한다

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

 

- space와 tab을 혼용하지 않는다

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

 

-쓰기가 잘 되어 있는지 확인하는 습관을 들인다.

 

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

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

 

-IDE의 코드 자동 정렬 기능을 활용한다

> 피드백 강의를 통해 알게되었고 2주차에는 이를 적용해보았다.

• IntelliJ IDEA: ⌥⌘L, Ctrl+Alt+L
• Eclipse: ⇧⌘F, Ctrl+Shift+F

---

7, Java에서 제공하는 API를 적극 활용한다

함수(메서드)를 직접 구현하기 전에 Java API에서 제공하는 기능인지 검색을 먼저 해본다.

Java API에서 제공하지 않을 경우 직접 구현한다.

예를 들어 사용자를 출력할 때 사용자가 2명 이상이면 쉼표(,) 기준으로 출력을 위한 문자열은 다음과 같이 구현 가능하다.

 

List<String> members = Arrays.asList("pobi", "jason"); String result = String.join(",", members); // "pobi,jason"

=> 이번 2주차의 자동차 경주 미션에 최종 우승자 출력 기능에 힌트가 되었다.

=> 내가 가장 갈증을 느끼고 있는 부분이기도 하다.

API를 한번 쭉보려면 기본적으로 자바 기본 문법에 익숙해야 하는데,

빨리 끝내고 API를 한번 쭉 볼 필요를 느꼈다.

 

 

8. 배열 대신 Java Collection을 사용한다

Java Collection 자료구조(List, Set, Map 등)를 사용하면 데이터를 조작할 때 다양한 API를 사용할 수 있다.

예를 들어 List<String>에 "pobi"라는 값이 포함되어 있는지는 다음과 같이 확인할 수 있다.

 

List<String> members = Arrays.asList("pobi", "jason"); boolean result = members.contains("pobi"); // true

=> 이것을 활용해서 이번 2주차에 Duplicated 내용 검사를 할 때

=> 리스트의 길이 == set의 길이로 중복여부를 결정해야겠다고 마음 먹었다.

 

---

전반적인 검토 및 느낀점

 

1. 커밋 메시지를  스코프와 함께 구체적으로 작성할 필요를 느꼈다.

2. 변수-메소드의 좋은 이름을 위해 시간을 들이자.

3. 자동 정렬 기능을 적극적으로 활용하자

4. 자바 API를 빠르게 익힐 필요성을 느꼈다.
- 코드 작성의 자유도 및 시간 절약에 큰 도움이 될 것 같다.