우아한테크코스 2주차 회고록 프리코스 목표변경
Description: 이 글은 우아한테크코스 프리코스 2주차를 되돌아보며 설정 목표를 변견한점, Max depth를3미만으로 유지 eslint사용등에 관해 이야기합니다
#000#IT_Knowledge#090#External_Insights#090.10#Activity#090.10 c#우아한테크코스_프리코스_2주차_회고록
우아한테크코스 프리코스 2주차 회고록
- 클래스 활용 하기위해 메소드 잘개 쪼개기
- 디스코드 봇만들기
프리코스 목표수정
커밋 리뷰 수 -> 커밋 리뷰 피드백 목록
기존의 커밋 메시지의 수와 긍정적인 정도를 질표로 삼았는데 수정을 하게 됐습니다
정량적인 지표로서 측정가능한 지표인줄 알았는데, 실제 해보니 느낀 것은 단순히 수의 측정이 중요한게 아니라 그를 통한 질적 성장이 중요한 것었습니다,
예를들어 커밋 리뷰수가 10개를 받아 칭찬만 받는 것보단 나를 성장시킬 커밋 리뷰 1개가 더 가치 있을 수 있다는 것입니다.
그래서 이전 주차에서 지적받은 사항을 이번주차는 얼마나 수정했느냐의 의미로 커밋 리뷰 리스트를 만들기로하였습니다. 모든 이에게 전달되는 공통피드백만하더라도 10개정도에 달하고, 1명당 5개정도의 리뷰를 주시니 그 양이 생각보다 꽤 된다는 것을 느꼈습니다.
이정도의 양만 스스로 소화를 한다면 성장할 수 있다고 생각하여 목표를 변경하였습니다.
회고록 방문자 조회 수 -> 디스코드 추천 봇 만들기
1주차회고록의 방문자수가 6이라는 데이터를 기록했기에 뭔가 변환가 필요하다 느꼈습니다. 데이터가 너무 작다보니 측정하는 의미가 없다고 해야하나? 직접 해보니 10미만의 조회수가 나온게 약간의 충격과 함께 이 수준에서라면 태그나, 그런 키워드 위주로 바움ㄴ자수가 늘어나지 글을 잘써서 늘어났다는 지표로 삼기에는 너무 작은 데이터 였습니다.
그래서 다른 목표를 무엇을 할까를 고민했는데 프리코스 커뮤니티의 인기많은 글을 보여 이것을 사람들이 쉽게 접근하기 힘들다 라는 문제를 해결하고싶었습니다. 프리코스 기간동안 열정넘치는 분들의 의견교환 답변등을 모두와 공유하면 좋겠다 생각을 했습니다. 버려지기 아까운 데이터라고 해야하나
거기에 추가적으로 프리코스 커뮤니티 기간에만 가능한 목표를 고민하다보니 결론적으로는 그럼 추천 디스코드 봇을 만들자라고 생각하게됐습니다.
프리코스 커뮤니티의 인기지표를 이모지수+서브 메시지 수 기반으로 합산하여 주 단위로 인기 있는 글을 추천해주는 봇이면 목표로서 구현과 함께 공유 가치 창출이라는 목적도 달성할 수 있기에 괜찮겠다는 생각이 들었습니다.
2주차에서의 주요 고민들
독립 함수는 depth0이지만 , 클래스내의 메소드는 depth1인가?
처음 내 생각
그런거같다. depth의 기준이 indent
라는 말은 결국 복잡성이라고보는데 함수내에서의 로직에대한 복잡성의 depth와 class내에서 로직에 대한 복잡성이 같은 함수라도 다르기 때문에.
실제로는 클래스의 function부터도 depth는 0이다
https://www.youtube.com/watch?v=bIeqAlmNRrA&t=2070s&ab_channel=우아한테크 (참고 영상)
클래스내의 메소드조차 depth 1이라고 가정한 상황에서 리팩토링하려니 도저히 안되는 것 같아 그 기준에 대해 찾아본 결과
우테코관련 본 리팩토링영상을 찾아볼 수 있었고, 여기서 클래스내의 메소드또한 depth0에서 시작하여 if가 depth1, 이후 for문이 depth 2인 것을 확인함.
depth를 어떻게 줄일까? 메소드의 if, for문 확인 후 분리하기
getRaceWinnersIndex(positions) {
let maxValue = Math.max(...positions);
let winnersIndex = [];
positions.forEach((value, index) => {
if (value === maxValue) {
winnersIndex.push(index);
}
})
여기서 depth 문제 되는 부분이 postions
에 대한 부분임을 인지하기
해당 기능 분석하기
- 최고점수 확인
- 경재자 위치 배열을 통해 최고점수인 경우 배열에 추가하기
중간의 if문을 따로 메소드로 분리하기에는 애매하고,foreach
가 명시적으로 이해하기도 쉬어서 쓰는게 나을것 같다고 판단
해당 로직자체를 메소드 화하기
foreach자체가 for문으로 indent 1을 사용하고, 여기서 if문에 의해 indent 1 추가로판단.
일반적으로 for
,if
가 하나 나오면 indent가 1라고생각하며 즉 그 로직을 메소드로만들것
결과적으로는 if 문을 분리하여 깊이를 1나 줄임
getRaceWinnersIndex(positions) {
const maxValue = this.getMaxValue(positions);
const winnersIndex = [];
positions.forEach((value, index) => {
this.addWinnerIndex(value, maxValue, index, winnersIndex);
});
return winnersIndex;
}
Alt + Shift + F로 해결되지 않는 포맷 문제 eslint를 처음 시도하며 깨달은 룰의 중요성
포맷팅에 대해서 잘모르지만 저번 1주차 공통 피드백에서 alt
+ shift
+ F
를 통해 포맷팅이 가능하다는 소리에 이걸로 문제가 다 해결 될줄 알았습니다. 하지만 메소드와 메소드사이가 빈줄이 있던 없던 결과가 똑같이 나와서 이 단축키만으로는 모든 포맷팅 문제가 해결이 되지 않는것 같다고 느꼈습니다. 그래서 eslint를 시도
먼저 시도 한 것은 클래스내의 메소드 사이에 빈줄 추가하기. 그래서 찾아본 결과 padding-line-between-statements
라는 룰을 설정하면 가능하다고 했지만 eslint결과 검출이 안됨... 문법에 문제가 있는가 싶어서 before와 after를 바꿔보던가, 최신 버전의 문법으로 수정해도 검출이 안됨. 그래서 AI에게 계속 물어봤는데도 안되다가, 세부 룰인 multiline-block-like
라는 단어 사용. 해당 룰덕분에 다른 문법사항이 검출 됐지만, 원하는 빈 줄은 출력이 안됨. 그래서 더 찾아본 결과 lines-between-class-members
라는 룰이 있고 해당 룰이 원하는 목적임을 알게됨.
eslint 사용하며 얻은 인사이트
eslint에서 중요한 것은 어떤 요구사항이 eslint rule과 대응 되는지를 판단하는 것
이 과정에서 eslint란 다양한룰이 있다는 것을 인지하고, 그것을 언제 어디서 사용하는것이 eslint의 주요 포인트임을 깨달음.
해당과정을 통해 얻은 eslint로 표현한 프로그래밍 요구사항을 다음과 같이 해석할 수 있어야함
삼항연산자를 금지해라 -> no-ternary
룰을 사용해라
최대 깊이를 2칸으로 해라 -> max-depth
설정을 2칸으로 해라
(공통피드백) if, for, while문 사이의 공백도 코딩 컨벤션이다. -> padding-line-between-statements
에서 multiline-block-like
를 사용해라
// 삼항연산자 금지
'no-ternary': 'error',
// 최대 깊이 2칸
'max-depth': ['error', 2],
// 키워드에 공백 필수
"padding-line-between-statements": [
{ blankLine: 'always', prev: 'multiline-block-like', next: '*' },
{ blankLine: 'always', prev: '*', next: 'multiline-block-like' }
]
eslint 참고
우테고5기 https://velog.io/@2wndrhs/알아두면-쓸데있는-ESLint-Prettier-설정-방법
우아한 블로그 https://techblog.woowahan.com/15903/
eslint 알고 사용하기 https://medium.com/@iamkjw/eslint-알고-사용하기-6babb63da4d6
우승자를 보여주는 로직을 Race에서 처리하느냐 Display에서 처리하느냐
우승자의 배열을 받아오는것까지는 Race에서 처리하는게 확실한데 이후 표기관련해서 이 배열을 통해 우승자의 이름을 알아내 출력하는 역할을 Race 에서 처리하느냐, display에서 처리하느냐를 고민함.
함수 분리결론
logic일지라도 display쪽 logic임으로 displaycontroller에서처리. 만약 race로직에서 display쪽 까지 책임지면 단일 책임 원칙 위반임. 부연 설명하면 race에서 displayt에서 보여져야할 우승자 이름까지 신경을 쓰게 되는 형태라는 의미. race는 정말 필요한 우승자 정보 인덱스 배열만 넘겨주는 것으로 합의. 이 인덱스 배열을 통해 출력하는것은 display쪽의 몫