언어 스터디 1주차 분량을 마쳤다.
Summary
미션 기간: 2/1(토) - 2/7(금)
코드리뷰 기간: 2/8(일) - 2/11(화)
참여 인원: 16명 (스터디원 14명 + 진행자 2명)
평균 스터디 시간 : 2시간 22분
나의 미션 구현
미션은 수식을 입력하면 계산해서 값을 반환하는 것이었다.
계산은 덧셈밖에 없었으며 ',', ':' 등이 연산자로 쓰인다.
>> 1,2:3
결과 : 6첫 번째 코드는 자바로 거의 처음 코딩해보는 것이었기에 언어에 대해 미숙했다. 또 기존에 짜왔던 코드는 백준 문제풀이 같이 한 파일로 짜거나 뭣도 모르고 프레임워크를 쓰던 코드들밖에 없었기에 책임, 의존성과 같은 개념이 생소했다. 하지만 수식을 연산자와 피연산자가 이어져있는 형태로 표현한 것은 좀 참신했다고 생각한다.
두 번째 코드는 깔끔하고 담백한 코드를 짜려고 노력해서 나온 코드이다. MVC 패턴을 적용하고,
우테코가 10월쯤이었나, 그렇다면 4달정도 지난 시점에서 같은 문제를 풀어보니 내가 한 노력들이 의미없지는 않은 것 같다.
static public int sequentialAdd(Operators operators, Expression expression) {
int sum = 0;
boolean addFlag = true;
LinkedList<Object> tokens = expression.getExpression();
for (Object token : tokens) {
if (token instanceof Integer && addFlag) {
addFlag = false;
sum = addExact(sum, (int) token);
} else if (token instanceof Character && !addFlag && operators.contains((char) token)) {
addFlag = true;
} else {
throw new IllegalArgumentException(Message.CALCULATION_EXCEPTION_MESSAGE);
}
}
if (addFlag) {
throw new IllegalArgumentException(Message.CALCULATION_EXCEPTION_MESSAGE);
}
return sum;
}
다음은 기존 코드가 가진 문제를 총망라하는 하나의 함수이다.
1. MVC에서 각 계층이 갖는 역할
우테코할 땐 MVC에 대한 이해가 없는 채로 시작했다. 다른 사람들이 하길래 왜 하는지도 모르고 도입해봤다. 모델은 대상에 대한 비지니스 로직을 포함해야하지만, 기존의 코드는 자료를 저장하는 구조로만 역할했다. 이에 Service 계층에서 모델의 비지니스 로직까지 흡수했다.
2. API 사용 미숙
제네릭에 대한 이해가 낮아 충분히 제네릭을 쓸 수 있는 상황들에도 쓰지 않았다. Stream API를 잘 쓰지 않고 굳이 for문을 돌리는 것도 비효율적이었다. 사실 수식의 구성을 Object에 냅다 담아버리는 것도 처음이었기에 저지를 수 있는 실수였다.
3. 책임 과중
Service 계층에 책임이 과중된 것 외에도, 하나의 함수에서 여러 책임을 가져서 코드가 깊어지고 길어졌다. 위 코드에서도 변환, 검증, 연산의 책임이 뭉쳐있다.
4. 의존성
의존성에 대한 개념을 충분히 이해하지 못해서 DI(의존성 주입)을 하지 못했을 뿐더러 무엇을 정적 함수, 변수로 둬야하는지에 대한 이해도 부족했다.
이번에 스터디에서 코드를 짤 때는 이와 같은 부분들을 최대한 보완해서 하려고 노력했다. 하지만 받은 리뷰가 별로 없어 지금의 코드에 무슨 문제가 있는지 충분히 파악하지는 못했다...
스터디에 대한 회고
4Ls 방법 (?)으로 회고를 진행해 보려 한다.
Like (좋았던 점)
- 이탈자 없이, 순탄히 첫 주차가 흘러갔다.
- 거의 모두가 매일 2시간씩 스터디했으며 모두가 미션 제출시각을 지켰다.
- 많은 스터디원들이 시간을 잘 준수했다.
Learned (배운 점)
- MVC 패턴, API 등에 대한 연습을 했다.
- 몇몇 스터디원이 MVC 패턴을 적용하기 위해 노력했다.
- 거의 모든 스터디원이 API를 적극적으로 활용하기위해 노력했다.
Laked (부족한 점)
- 방법과 절차를 찬찬히 설명할 필요가 있다.
- 스터디원들이 코드 리뷰의 데드라인을 못 맞춘 줄 알았는데 리뷰를 게시하지 않아서(Finish Review를 누르지 않아서) 안 보였던 것이었다.
-> 신경써서 일찍일찍 노티와 안내를 해야겠다.
- 채점용 테스트코드가 부적절하다.
- 백엔드에게만 너무 가혹하다. (JS에서 그렇게 문제가 없을줄은 몰랐죠...)
- 코드를 잘 짠 사람이 더 많이 통과하는 것 같지 않다.
-> 채점용 테스트에 대해 스터디에서 얘기해볼 필요가 있다... 테스트코드를 굵직한 예외만 하고 동점일 경우 다른 기준을 통해 경품(?)을 주는게 어떨지 생각중이다.
- 리뷰가 날카롭지 않았다...
- 생각보다 비판적인 리뷰가 많지 않았다. 리뷰의 갯수 역시 충분하지 않았다.
- 벌칙 수행이 제대로 되지 않는다...ㅠ
- 포멧이 종종 맞지 않는다.
- 미션 파일의 입출력 포멧이 맞지 않거나 스터디에서 하기로한 양식에 맞지 않는 경우가 종종 있다
Loged for (희망 사항)
- 의존성에 대해 공부하면 좋을 것 같다.
- 단위테스트에 대해서도 공부할 필요가 있다.
- 스터디에 대한 열정이 지속되었으면 좋겠다.
