과제 진행
1일차
수요일에는 수업이 5시까지 있고 아직 시험기간이 겹쳐서 과제를 시작하지 않고 간단하게 어떤 과제를 구현해야하는지 살펴보기만 했는데 생각보다 난이도가 쉬워서 할만하겠다고 생각했다.
2일차 ~ 3일차
첫 번째 문제를 다 풀었을때 쯤 프리코스에서 소스를 작성 할때 지켜야하는 규칙이 기능 단위로 커밋하는 부분 밖에 없는줄 알았는데 우테코 클린코드 가이드 여러 조건이 있는걸 보고 다시 작성 했다.
우테코 프리코스 1주차 온보딩
문제가 원래 프리코스 코딩 테스트용으로 작성된 것인지 5번까지는 간단했다.
6번부터 난이도가 올랐는데, 구현 목록을 작성 했을때, 단순하게 브루트 포스 방법으로 구현할려고 했는데 제한사항에 크루가 최대 1만명, 닉네임이 최대 19자라 시간복잡도가 너무 많이 나오는것 같아 Map자료형을 통해 구현
6번 부터 우테코 클린코드 가이드 지키면서 코드를 작성하는데 고민을 어느정도 하게되는 문제이다.
"구현 전 기능 목록을 만들고 기능 단위로 커밋하라"
- 구현전에 미리 기능을 분석했다.
- 분석한 기능을 통해 어떻게 구현할지 기능 목록을 작상했다.
- 예외 케이스를 생각해서 작성
4일차 ~ 6일차
7번 문제 기능 분석 및 기능 목록 작성
6번과 비슷하게 Map 자료형을 통해 접근하고, 기능을 세부적으로 쪼개어 하나씩 구현하니 금방 완성 됬다.
1주차 공통 피드백 체크
요구사항을 정확하게 준수한다.
과제 제출 전에 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항의 항목을 모두 잘지켰는지 확인한다.
1주차에 slack에 테스트 케이스를 추가해도 되는지 질문을 했었는데, 답변을 받지 못해서 혹시 테스트 케이스를 통해 채점이 이뤄질까봐 테스트 케이스를 따로 추가하지 않았다.
요구사항을 정확하게 준수하는지 가장 빠르게 확인하는 법은 테스트 케이스를 작성하고 테스트 케이스의 통과하면다면 내가 분석한 요구 사항은 모두 통과 한다는걸 보장 받을 수 있을 것 이다.
커밋 메시지를 의미 있게 작성한다
커밋 메시지에 해당 커밋에서 작업한 내용에 대한 이해가 가능하도록 작성한다.
1주차 과제를 하면서 이 부분을 잘 지키지 못한거 같다.
제목은 명령조로
우리말로 제목을 요약하는 경우라면 때로는 '문장'보다 '구문'을 더 선호할 때도 있습니다.
인증 메소드 수정
* CABVerification.java: 15번째 줄 인증 메소드의 인자를 현 정책에 맞게 고쳤다.
* JSONFormat.java: 이 커밋은 이 파일에 적절한 로깅 메소드를 추가한다.
* MainView.java: 약간의 리팩토링.본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기
좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 - NHN
git을 통해 관리할 자원에 대해서도 고려한다
gitignore 관리 필요
gitignore 파일 자동 생성
이름을 통해 의도를 드러낸다
나 자신, 다른 개발자와의 소통을 위해 가장 중요한 활동 중의 하나가 좋은 이름 짓기이다. 변수 이름, 함수(메서드) 이름, 클래스 이름을 짓는데 시간을 투자하라. 이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내기 위해 노력하라. 연속된 숫자를 덧붙이거나(a1, a2, ..., aN), 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.
이 부분은 신경쓰면서 코딩하긴 했지만 내가 봤을때는 어떤 기능을 하고 있는지 알겠는 데 남들이 봤을때는 잘 이해가 되는지 모르겠다. 피어리뷰를 받아봐야겠다.
좋은 코드를 위한 자바 변수명 네이밍
공백도 코딩 컨벤션이다
if, for, while문 사이의 공백도 코딩 컨벤션이다.
공백 라인을 의미 있게 사용한다
공백 라인을 의미 있게 사용하는 것이 좋아 보이며, 문맥을 분리하는 부분에 사용하는 것이 좋다. 과도한 공백은 다른 개발자에게 의문을 줄 수 있다.
space와 tab을 혼용하지 않는다
들여쓰기에 space와 tab을 혼용하지 않는다. 둘 중에 하나만 사용한다. 확신이 서지 않으면 pull request를 보낸 후 들여쓰기가 잘 되어 있는지 확인하는 습관을 들인다.
위 3부분은 인텔리제이로 구글 포메터를 적용하여 사용했기 때문에 다 지켰을 것이다.
의미 없는 주석을 달지 않는다
변수 이름, 함수(메서드) 이름을 통해 어떤 의도인지가 드러난다면 굳이 주석을 달지 않는다. 모든 변수와 함수에 주석을 달기보다 가능하면 이름을 통해 의도를 드러내고, 의도를 드러내기 힘든 경우 주석을 다는 연습을 한다.
함수, 변수 네이밍에 신경을 열심히 써서 주석을 거의 쓰지 않았다.
Java에서 제공하는 API를 적극 활용한다
함수(메서드)를 직접 구현하기 전에 Java API에서 제공하는 기능인지 검색을 먼저 해본다.
Java API에서 제공하지 않을 경우 직접 구현한다.
예를 들어 사용자를 출력할 때 사용자가 2명 이상이면 쉼표(,) 기준으로 출력을 위한 문자열은 다음과 같이 구현 가능하다.
배열 대신 Java Collection을 사용한다
Java Collection 자료구조(List, Set, Map 등)를 사용하면 데이터를 조작할 때 다양한 API를 사용할 수 있다.
느낀점
학교에서하는 프로젝트를 할때 항상 시간에 쫓기고, 코드 스타일이나 유지보수 이런 부분이 아니라 구현에 대해 평가받다 보니 항상 변수, 함수 등에 네이밍 보다 구현에만 초점을 맞추고 프로젝트를 진행 했던것 같다.
42Seoul 프로젝트는 동료에게 평가를 받아야 해서 그래도 네이밍에 신경을 쓰긴 했지만, 42Norminette에 걸리는 경우 때문에 변수명을 축약하는 경우도 많았다.
프리코스 온보딩 과제를 통해 변수명 작성하는 법, git commit 메시지 작성법 등에 고민하고 또 가장 지키기 어려웠던 부분이 한 "메서드에 오직 한 단계의 들여쓰기(indent)만 허용했는가?" 였다.
반복문안에서 조건문을 처리하고 싶은데 이 부분을 어떻게 나눠야 할지 고민 계속하다 결국 반복문 안에서 처리했다. 다른 사람의 소스를 리뷰해주면서 어떻게 처리했는지 살펴봤지만 대부분 "메서드에 오직 한 단계의 들여쓰기(indent)만 허용했는가?" 는 잘 지키지 못한거 같았다.
