[우아한 테크코스 5기] 프리코스 1주차 회고 (Convention과 Clean Code)

회고의 시작

지난 경험을 기억하고 같은 실수를 반복하지 않기 위해 그리고 글쓰기 능력을 위해 우테코 프리코스 과정을 기록해두려고 합니다.

회고를 작성하기전 어떻게하면 "나에게 맞는 회고를 쓸 수 있을까?" 고민을 해보았습니다.

우선, 기존에 하루씩 작성하던 수수나 님의 TIL 챌린지 양식으로 회고를 작성해도 괜찮겠다는 생각을 했지만,

개인적으로 잘한점을 찾아서 적는다는게 쉽지 않았고, 하루가 아닌 일주일이라는 점에서

김창준님의 글, 되돌아보다의 5Fs 양식으로 작성해보려고 합니다.

※ 기존 TIL 방식과 5Fs의 차이

잘한점

→ Facts(한 것)

+ Feelings(느낀점)

배운점 → Findings(배운점)

개선점 → Future Actions(개선점)

+ Feedbacks(시간이 지난후 결과)

차이점 : [TIL] 하루의 특정 상황에서 잘한점, 배운점, 어려운 웠던 부분에 대해 개선점을 찾는것

  → [5Fs] 일주일간 한 것들을 정리하고 느낀점, 배운점, 개선점, 일정 시간이 지난후 결과(피드백)를 작성한다.

---

한 것

프리코스 1주차 시작에 앞서서 진행하는 과정동안 그리고 앞으로 작성할 코드들에 대해서도

나만의 규칙을 확립하는게 중요하다고 생각했고 꾸준히 할 수 있도록 최소한으로 할 수 있는 것들에 대해 계획을 세워보았습니다.

계획

Convetion(규칙)은 최소한으로 Java Code, Commit 메시지에 대해서만 계획해보았습니다.

 

1. Java Convention & Clean Code

 

캠퍼스 핵데이 Java 코딩 컨벤션
Google Java Style Guide

자바 컨벤션은 위의 규칙들을 읽어보며 따라 사용하기 보다는 얼마나 상세하게 컨벤션을 적용하는지 파악했습니다.

그 후, 컨벤션을 유의하며 코드를 작성하고 IDE에 Google 컨밴션 xml을 적용해 까먹은 부분을 warning으로 띄워 어떤 부분이 잘못됐는지 확인 했습니다.

 

막연히 Clean Code라고 하면 의미있는 이름 짓기등 말은 쉽지만, 적용하기 어려운 부분이 많았습니다.

그렇기 때문에, "정량적인 규칙을 세우고 Code를 짜보자." 라는 계획을 세워보았습니다.

이 부분은 "객체 지향 생활 체조 원칙"에서 최대한 나에게 맞는 부분을 타협하여 사용하였습니다.

 

1. 들여쓰기는 2단계 까지

2. else 예약어 쓰지 않기.

3. 줄여 쓰지 않는다.

4. 모든 엔티티를 작게 유지한다.

5. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.

 

2. Git Commit Convetion

Java 코드도 중요하지만, 프로젝트를 진행하면서 변경과 오류 해결과정도 굉장히 중요합니다.

Git Commit Convetion은 여러 블로그를 참조해보며 아래와 같은 규칙을 적용하였습니다.

{Commit 타입} : {짧은 설명}

{자세한 설명(필요하지 않은경우 생략)}

예시) Git Commit Convetion

이러한 방법이 익숙하지 않아, 인텔리제이 플러그인 'Git Commit Template'을 설정해서

기억이 안나는 상황을 대비해 두었습니다.

Commit Template 플러그인 화면

프리코스 1주차 미션진행

일단 하나의 관련된 문제가 아닌 7개의 다른 문제로 구성되어 있어 다음과 같이 패키지 구조를 나눴습니다.

프리코스 1주차 패키지 구조

그 후, README로 문제마다 구현 기능 목록을 작성하고 제한사항을 유의하며 클래스를 설계했습니다.

클래스를 작성할 때 사용자에게 최대한 구현 로직을 숨기기 위해 생성자와 결과에 관련된 로직만 나타내려고 했습니다.

사용자가 사용할 때는 PageGame을 생성하고 result만 사용하도록..

 

---

느낀 점

1주차 프리코스를 훑어보면서 구현이 그렇게 어렵지 않겠다고 생각했습니다.
그런데, 클린코드, 커밋 단위, 테스트 단위등을 고려하며 설계하려니 생각한것 보다 많이 어려웠습니다.

 

이런 과정속에서 기계적으로 하던 커밋에서 효율적인 단위의 커밋, 프로덕트 코드에서 어떻게 테스트 코드를 작성할 지, 구현 기능 목록을 어떻게 작성해야 되는지 등 많은 고민을 하며 부족함을 많이 느꼈습니다.

 

또한, 프리코스 과제를 제출할 때, 리뷰를 작성해야 하는데, 글을 잘 쓰지 못하는 저에게 정말 어려웠던 부분이었습니다.

이를 해결하기 위해서는 역시 많이 작성 해봐야 늘 것 같습니다.

시간을 투자해 회고를 쓰는 이유...
언젠가 내가 표현하는 부분을 글로 잘담아 낼 수 있길바라며...!

---

배운 점

기존에 코드 배치를 접근 제어자 단위로 했다가 문득, "메소드 배치는 어떻게하는게 좋을까?"라는 의문이 들어

자료를 찾아보니 "최대한 기능별로 응집도 있게 배치하는 게 알아보기 쉬운 코드"라는 걸 배웠습니다.

이번에 커밋 단위를 어떻게 할 지 고민하면서, 기능 구현 부분(feat)에서는 하나의 기능에 대해 테스트 코드 + 프로덕트 코드를 커밋 단위로 묶는게 효율적이었습니다. 

기존에는 하나의 기능에 대해 테스트 코드를 test , 프로덕트 코드를 feat로 나눠서 커밋을 보냈습니다.

그런데, 이는 비효율적이라고 느꼈고 테스트 코드에 맞혀서 프로덕트 코드를 구성할 때는 하나로 묶어서 커밋하는게 효율적이라고 느꼈습니다. 

---

개선점

구현 기능 목록을 가능한 작은 단위로 작성하고 이를 토대로 개발하는 것에 신경쓰자. 

(7번 부분에서 구현 기능을 크게 잡으니 테스트도 어려웠습니다.)

 

커밋 메시지를 읽기 좋게 작성하자.

(커밋 메시지를 작성할 때는 몰랐지만, 1주차가 끝나고, 다시 커밋 메시지를 확인해보니, 몇 번 문제의 어떤 기능을 구현했는지 바로 바로 확인이 힘들었습니다.)

---

시간이 지난후 결과

(좌) 1주차 문제1 구현 기능 목록 / (우) 2주차 숫자 야구 게임 구현 기능 목록

1주차에서 구현 기능 목록을 프로그래밍 요구사항을 토대로 큰 틀만 잡아두고 끝을 냈다면

2주차에서는 프로그래밍 요구사항을 토대로 Todo리스트를 작성하고 기능 구현을 하면서 구체적으로 작성해 나갔습니다.

 

마크다운 문서를 작성할 때, '[x]' 문법을 사용하니 현재 어디까지 구현이 되어있고, 어느 부분을 완성해야 될 지, 한 눈에 보였습니다. 

또한, 외관상으로도 1주차에 비해 2주차 구현 기능 목록은 기능별로 분리가 잘 되었다는 느낌이 듭니다.

 

(좌) 1주차 커밋 메시지 / (우) 2주차 커밋 메시지

커밋 메시지 같은 경우는 커밋 타입 옆에 범위를 지정해주고 구현 기능 목록을 토대로 메시지를 작성하려고 하였습니다.

확실히, 이렇게 작성하니 1주차 커밋 메시지에 비해 2주차 커밋 메시지는 어느 범위에서 변경이 일어났는지 조금 더 명확해졌습니다.