[우테코 5기] 프리코스 1주차 회고록

 

다사다난했던 우테코 1주차 회고록을 작성해보려 한다.

뭔가 형식과 틀에 맞춰 작성하기보단 내가 느낀 감정과 경험을 글로 남기고자 한다.

 

우선 우테코 1주차는 너무나도 정신이 없었다. 대학 중간고사 주간과 우테코 1주차가 겹쳐서 너무 힘들었다. 심지어 제일 중요했던 주말엔 최근 2주간 하루 4시간으로 잠을 줄이고 무리했던 탓에 독감에 걸려버렸다. 그래도 약으로 버티면서 어찌저찌 시험과 우테코 1주차를 마무리할 수 있었다.

정신없었던 것 치고는 그래도 상당히 좋은 경험을 한 것 같아 기분은 좋았다.

 

 

이제 본론으로 돌아가겠다.
우테코 1주차는 7개의 알고리즘 문제 풀이로 진행되었다.

백엔드 포지션을 택한 나는 자바를 통해 기능 구현을 해야 했다.

자바 알고리즘 문제 풀이는 평소 스프링으로 서버를 개발할 때 얼마나 성의 없이 해왔는지 뼈저리게 느끼게 해 주었다.

때문에 이 기회를 이용해 깊이 있는 자바 학습을 해보고자 클린 코드를 신경 쓰며 개발했다.



Clean Code

:: else문 지양


else문은 if문의 가독성을 떨어뜨리고 명확하지 않다는 이유로 지양해야 한다고 배웠다. 때문에 if문으로 최대한 해결할 수 있도록 코드를 구현하였다.

 

:: 기능 단위로 메서드 구현


메서드 또한 기능 단위로 착실히 구현하였다. 객체 지향의 SOLID원칙 중 SRP 규칙에 따라 당연히 해야 하는 부분이지만 사실 이것에 신경을 크게 못써왔던 것 같아 신경 쓰며 신중하게 코딩하였다.

 

:: 매직 넘버 사용 지양


프로그래밍에서 상수로 선언하지 않은 숫자를 매직 넘버라 부른다. 만약 A가 개발한 코드에 반복문 for(int i = 0;i < 3;i++) 가 있다고 가정할 때, 1년 뒤 코드를 넘겨받은 B가 3을 어떻게 이해할 수 있겠는가? 여기서 3이 바로 매직 넘버이다. 지정된 수에 변수명을 붙여 상수로 사용하지 않으면 그 수가 의미하는 바를 파악하기란 쉽지 않은 일이다. 때문에 이번 기능 구현 과정에서는 매직 넘버를 지양하여 개발하였다.

 

:: depth 신경 쓰며 구현


코드의 depth가 깊어질수록 코드는 가독성이 낮은 못생긴 코드가 된다. 코드에서 depth(깊이)는 아래와 같이 계산할 수 있다.

public void test(){
	int a=1;
	if(a > 0){
		//depth 1
		for(int i = 0;i < 10;i++){
			//depth 2
			System.out.println(i);
		}
	}	
}

아직 depth가 2밖에 되지 않는데도 중괄호에 의해 코드가 너무 지저분해 보인다.

여기서 depth가 더 늘어나고 코드가 길어지면 이해하기 힘든 코드로 전락하고 말 것이다.

때문에 depth를 최대한 2를 넘기지 않도록 생각하며 개발하였다.

 

 

깃허브

:: 기능 단위 커밋


깃 커밋은 기능 단위로 분할하여 커밋하였다. 기능은 README.md 파일에 정리하고 그에 맞게 커밋하려고 노력했다. 코딩하는 것보다 기능을 정리하는 것이 훨씬 복잡하고 머리 아팠다. 이 부분은 연습이 많이 필요할 것 같다.

 

:: 커밋 컨벤션


커밋 컨벤션을 정하고 그에 맞춰 커밋하였다. 이렇게 하니 내가 문서 수정을 한 것인지, 기능을 구현한 것인지, 리팩터링을 한 것인지 확실하게 알 수 있었다. 특히 지정한 커밋 컨벤션을 편하게 기억하기 위한 깃허브의 명령어를 알아내어 편하게 사용했다.

 

git config —global commit.template .gitmessage.txt

터미널에서 사용할 수 있는 명령어인데 .gitmessage.txt를 커밋할 때 자동으로 커밋 메세지로 설정해주는 명령어이다.

이 덕분에 잊지 않고 커밋 컨벤션을 지킬 수 있었다.

 

 

.gitmessage.txt

# <타입> : <제목> 형식으로 작성하며 제목은 최대 50글자 정도로만 입력
# 제목을 아랫줄에 작성, 제목 끝에 마침표 금지, 무엇을 했는지 명확하게 작성

################
# 본문(추가 설명)을 아랫줄에 작성

################
# 꼬릿말(footer)을 아랫줄에 작성 (관련된 이슈 번호 등 추가)

################
# feat : 새로운 기능 추가
# fix : 버그 수정
# docs : 문서 수정
# test : 테스트 코드 추가
# refactor : 코드 리팩토링
# style : 코드 의미에 영향을 주지 않는 변경사항
# chore : 빌드 부분 혹은 패키지 매니저 수정사항
################

 

 

부족했던 점

:: 네이밍


변수와 메서드 네이밍이 생각보다 많이 막혔다. 개발자의 의도를 가장 잘 드러낼 수 있는 것이 바로 네이밍인데 가장 중요한 네이밍이 막혔다는 것이 부끄러웠다. 이번 기회를 통해 영어 공부도 열심히 하고 감도 많이 익혀야겠다고 느꼈다. 변수명은 명사로! 메서드명은 동사로!

 

변수명을 지어주는 사이트가 있어 많이 도움받았다.

 

Curioustore

변수명 짓기, 컬럼명 짓기, 영어약자, 変数名 つけ方, カラム名建てる, 英語の略語, 命名变量, 命名该列, 英文缩写

www.curioustore.com

 

:: 깃 사용 미숙


깃 사용이 상당히 미숙했다는 것을 다시 한번 느꼈다. 노트북 2개를 사용해 개발하다 보니 커밋이 꼬여서 레퍼지토리를 삭제하는 상황까지 가버렸다.

 

깃 공부를 평소 많이 해두지 않았던 나의 잘못인 것 같다.

틈틈이 공부해서 이와 같은 사태가 벌어지지 않도록 해야겠다

 

 

 

 

.