[회고] 우아한테크코스 5기 프리코스 2주 차 회고

1주 차 피드백

2주 차 과제를 제출한 후 이제야 회고록을 작성해본다. 우선 이번 2주 차 과제에서는 특별한 자료와 함께 메일이 도착했다. 1주 차 과제 공통 피드백과 무려 우테코에서 직접 촬영한 git 강의가 같이 있었다.

또한 우테코 이전 기수 분들이 촬영한 테코톡 영상 또한 첨부되어 있었는데, 정말 특별한 우테코만의 문화라고 생각한다. 나도 내년에 저기(테코톡)에 나오면 좋겠다.

우테코 관리자 분들이 약 3300명 정도 되는 규모의 인원의 코드들을 하나씩 살펴볼 수는 없기에 공통 피드백을 준 것 같지만, 그래도 나름 1주 차 과제가 힘겨웠던 분들을 생각해서 강의 자료나 피드백들을 상세하게 주셨다. 진행하면 할수록 더 매력적이다..

피드백 중에서 기억에 남는 것이 있었는데, 메서드나 변수명을 축약하지 말라는 피드백이었다. 나는 클린코드란 코드가 정말 깔끔하기만 하면 되는 줄 알았다. 하지만 나만 볼 수 있는 깔끔한 코드는 클린 코드가 아닌 것이었다.

의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.
누구나 실은 클래스, 메서드, 또는 변수의 이름을 줄이려는 유혹에 곧잘 빠지곤 한다. 그런 유혹을 뿌리쳐라. 축약은 혼란을 야기하며, 더 큰 문제를 숨기는 경향이 있다.

이 문구를 보고는 내가 저 유혹에 너무 빠졌던 것이 아닌가를 생각해 봄과 동시에 내가 이때까지 지은 변수, 메서드명들이 남이 알아볼 수 있었을까에 대한 물음표도 있었다.

우테코에서는 기능을 구현하기 전 기능 목록을 먼저 만들고 시작하는 것을 강조한다. 하지만 내가 이때까지 사용했던 리드미 파일은 깃허브 꾸미기 뿐이었던가. 기능 목록을 먼저 작성하고 기능을 구현하는 방식은 나에게 익숙하지 않았다.

기능 목록을 작성하면 시간도 오래걸리고 그 범위 내에서만 개발과 구현이 이루어진다고 합리화를 하기도 했었다. 하지만 우테코에서 시키는 데에는 다 이유가 있는 것 같다.

내가 생각하는 리드미 파일에서 기능 목록을 작성하니 장점이 여럿 있었다.

개발자는 개발만 신경쓰면 된다는 마인드를 깨고 항상 프로젝트는 개발뿐만 아니라 기획과 디자인이 너무나도 중요하다는 것을 다시 한번 리마인드 할 수 있는 시간이었다.

이번 2주차 과제에서는 특이하면서도 정말 코드를 깔끔하게 분리시킬 수 있도록 해주는 요구사항이 있었는데, 바로

indent(인덴트, 들여 쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.
- 예를 들어 while문 안에 if문이 있으면 들여 쓰기는 2이다.
- 힌트: indent(인덴트, 들여쓰기) depth를 줄이는 좋은 방법은 함수(또는 메서드)를 분리하면 된다.

였다.

그런데 나는 이런 생각이 들었다. while문 안에 if문이 있을 때 중괄호를 생략하지 않으면 인덴트가 3이 되는 건가? 내 궁금증을 예로 들면 아래와 같다.

for (int i = 0; i < AGE; i++) {
    if (i % 3 == 0) {
        System.out.print("3으로 나누어 떨어지는 수");
    }
}

이 문제는 뭔가 나 혼자 생각으로만 해결될 것 같지 않아서 슬랙에 질문도 해보았다.

하지만 무수한 눈알이 달려서 나 혼자 조금 더 생각해봤는데 while문 안에 if문이 있으면 2이며, 우테코에서 말하기를 중괄호는 생략하지 않는다고 했기에, 위와 같은 형식은 인덴트가 2라고 내 머릿속의 컨벤션에 저장했다. (합리화일 수도 있음..)

테스트 케이스를 작성하는 시간만큼 효율이 나올까? 테스트 케이스의 장단점은 아래와 같다.

장점
- 예상 동작과 실제 동작을 비교하여 빠르고 정확한 테스트가 가능하기 때문에 초기 개발의 디버깅이 쉬워진다.
- 애플리케이션이 변경(기능 확장 또는 리팩터링 등)되더라도 올바르게 작동하는지 확인할 수 있다.
- 단위 테스트 자체를 어플리케이션에 대한 문서로 사용할 수 있다. 특히 잘 만든 테스트 케이스는 API 기능을 쉽게 파악할 수 있도록 도와준다.
- 여러 빌드 도구들(maven, gradle 등)은 테스트 자동화 기능을 포함하고 있다.
단점
- 테스트 코드까지 작성해야하기 때문에 개발 시간이 오래 걸리게 된다.
- 애플리케이션 변경 사항을 테스트 코드에도 적용해야 하기 때문에 테스트 코드를 유지 보수하는 비용이 든다.

솔직하게 개발 비용이 조금 더 드는 것 말고는 단점이랄 것도 없는데에다가 장점이 워낙 강력해서 사용할 수밖에 없는 테스트 케이스다. 하지만 나는 이걸 알면서도 기존 프로젝트에서 테스트케이스를 작성하지 않았었다.

백엔드는 API를 만들게 되는데 이 API를 Postman이라는 외부 툴(Tool)로 테스트하였고, 여기서 또한 문서화가 가능했기에 더 많은 시간을 들여야 하는 테스트 케이스 작성을 꺼렸었다.

하지만 이번 숫자야구게임에서 테스트케이스를 작성하며, 디버깅 단계에서 단위 테스트나 기능 테스트를 진행할 수 있다는 점에서 생산성을 가져가고, 애플리케이션 변경에 대한 테스트를 하는데에 있어서 매우 좋다고 느꼈다.

결론은 테스트케이스를 작성하는 시간만큼의 효율은 절대적으로 더 많이 나오니, 작성하는 것이 좋다.

이번 프리코스 2주 차 과제에서는 함수를 분리하고 각 함수 별로 단위 테스트를 하는 것에 익숙해지는 것이 목표라고 했다. 1주 차 목표에 비하면 내가 기대했던 프리코스의 소목표인 것 같았다.

또한 우테코 5기에 지원한 사람들 (이하 크루)이랑 소통할 수 있는 깃허브 디스커션이 만들어졌는데, 같은 문제를 가지고 토론하고, 내 생각과 어떻게 다르면서 이렇고 저런 방식으로 해결하면 어떤게 좋은지에 대한 인사이트도 많이 얻을 수 있었다.

크루들끼리 같이 성장할 수 있는 환경. 이게 진정한 우테코의 묘미가 아닌가 싶었다. 다른 사람들이 작성한 코드도 자기 자신의 코드처럼 자세히 보고 리뷰해주는 것이 정말 인상 깊었다.

3주 차 과제도 잘 끝내고 회고를 끄적여보도록 하겠다. ㅂ2 ㅂ2👋