💡 코수타

남은 인원

모바일 안드로이드 200명
프론트엔드 800명
백엔드 2500명

코드리뷰 팁

실무보다는 프리코스를 위한 코드리뷰를 해야한다.
서로 같이 성장하는 것이 목적이기 때문에, 남을 비방하기보다는 권유하는 말투로 하자.
리뷰를 받는 입장에서는, 코드와 본인을 떼 놓고 보도록 하자. => 기분 나빠하지 말고, 얻어갈 수 있는 것들을 얻어가자.
지금 단계에서는, 코드를 한 번 실행해보는 것이 중요하다.

권장하는 코드리뷰 시간은?

리뷰가 처음이라면, 기본적인 기능 요구사항을 만족한 코드인지를 중점으로 두고 리뷰해보자. 그 후로는 프로그램 요구사항을 중점으로 두어보고, 그 후로는 설계와 아키텍처 부분까지 고민해볼 수 있는데 아직 그 단계까지 할 필요는 없다.

어떻게 하면 코드리뷰를 잘 받을 수 있을까?

우선은 많은 사람들에게 코드리뷰를 해주는 것이 필요하다. 이미 리뷰가 많이 된 PR은 읽어보고 도움을 받고, 리뷰가 많이 되지 않은 곳에 찾아가서 이를 적용해 리뷰를 진행해보자.

수준이 맞는 사람끼리 코드리뷰를 해야 할까?

현업에서도 이와 비슷하게, 주니어가 시니어의 코드를 리뷰해주는 경우도 많다. 코드 리뷰라고 꼭 거창하게 할 필요가 없다. 그저 칭찬을 하고 질문을 해보아도 괜찮다. 예를 들어 음식을 먹는 입장에서도, ‘맛있다’, ‘보기 좋다’ 라고 간단하게 칭찬을 할 수 있는데, 꼭 ‘이 재료보다는 다른 게 더 나을 것 같다.’ 처럼 말할 필요는 없는 것처럼 말이다.

”스스로 생각해보세요.”

정말 많은 문의가 들어왔는데, 90% 이상의 질문에 “스스로 생각해보세요.” 혹은 “형평성 상 말씀드릴 수 없습니다.” 로 답변을 하였다. 숫자야구 게임은 이미 5년째 진행되고 있는 미션이기 때문에, 오류는 없다고 봐도 된다.

몰입, 프로그래밍, 현장

300라인 정도의 작은 애플리케이션을 만들 정도의 기초적인 프로그래밍 역량을 가지고 있어야 한다. 이를 기준으로 문제를 출제하고 있다. 현장에서는 100% 완전한 요구사항이 내려오지 않는다. 심지어는 개발과 기획을 동시에 진행하는 경우도 있다. 그러므로 개발자가 스스로 예외사항과 방어 로직 등을 생각할 수 있는 역량을 기르는 것도 필요하다.

”작년에는 이랬는데..”

작년과 비교하지 마라. 제일 중요한 것은 미션의 요구사항 대로 프로그래밍 하는 것이다. 그러므로 올해의 것에만 제대로 집중하도록 노력하자.

”저 사람은 잘한다. 저 사람은 못한다.”

경쟁 사회에서 계속 살아왔기 때문에 남과 자꾸 비교하게 되는데, 어차피 코치들이 보기에는 다 똑같으니 그런 생각을 하지 말고 할 일을 열심히 하는 걸 추천하고 싶다. 현재 우테코하는 크루들 중에서도 “내가 왜 뽑혔는지 모르겠어요.” 하는 사람들도 많다. 남에게 관심을 가질 때는 코드 리뷰를 할 때만이고, 평소에는 어제의 나와만 비교하도록 하자.

소감문에 링크로 첨부해도 되나요?

상관은 없지만, 글자 수 제한이 있기도 하기 때문에 그냥 솔직담백한 심정을 소감문 칸에다 써주는 게 더 좋을 것 같다.

우테코 본코스와 프리코스의 차이점은?

우선은 가장 큰 차이점은 코드 리뷰를 실무의 전문 리뷰어에게 받을 수 있다. 그리고 코치분들과 자연스럽게 더 가까워지게 된다. 우테코 테코톡을 진행할 기회도 주어진다.

💡 공통 피드백

1주차에 코치분께서 공통적으로 제공한 피드백입니다.

앞으로 매주 제가 제출한 코드를 기반으로, 잘 이행했는지를 확인하여 1~5점 까지 저에게 점수를 매기며 작성할 생각입니다!

요구사항을 정확히 준수한다. (4점)

리드미와 메일을 최대한 꼼꼼히 보면서 놓친 부분이 없나 생각을 많이 했었습니다. 하지만 기능구현을 모두 마쳤다고 안심한 후에 다시 보니, 출력에서 사소하게 잘못된 부분이 있음을 알았습니다.

또한 리드미에서 사용하는 힌트와 같은 용어들을 활용하지 못 한 점도 아쉬웠습니다.

이러한 모습을 보면서 MVC 패턴 등 새로운 걸 시도하려는 것도 중요하지만, 주어진 요구사항을 잘 맞추는 것이 무엇보다 중요하다는 것을 다시금 상기시킬 수 있었습니다.

커밋 메세지를 의미 있게 작성한다. (5점)

이 부분은 처음부터 고민을 했어서, 커밋 컨벤션 파일도 작성하면서 최대한 꼼꼼히 커밋 메세지를 작성했습니다.

물론 그럼에도 부족한 부분이 있었겠지만, 커밋 메세지의 중요성을 스스로 깨닫고 실제로 실천해보았다는 점에서 의미가 있는 듯합니다!

git을 통해 관리할 자원에 대해서도 고려한다. (1점)

이 부분은 전혀 생각치 못한 부분이라서 놀랐습니다.

기존에도 프로젝트를 만들고 현재 폴더에 있는 모든 파일을 커밋하고 푸시했었습니다. 그리고 그게 맞다고 생각했습니다. 누군가가 클론을 해서 사용하려면 모든 파일이 있어야 실행이 될 것이라 생각했기 때문입니다.

하지만 인텔리제이의 .idea와 같은 폴더들은 개발 도구가 자동으로 생성해주기 때문에, 굳이 깃 저장소에 올려 관리할 필요가 없었습니다.

해당 피드백을 보면서 깃에 올려서 관리해야 할 파일들이 무엇이 있는지 파악하는 연습도 해보아야 겠다는 생각이 들었습니다. 더불어 아직 깃허브에 대한 기본적인 이해도 부족하다는 생각이 들어, 더욱 공부해야겠다고 느꼈습니다.

PR을 보내기 전 브랜치를 확인한다. (5점)

미션 제출 방법 문서에도 잘 나와있었기 때문에 잘 진행한 것 같습니다.

실제로 프로젝트를 할 때에도, 포크를 한 후에 브랜치를 새로 만들어 기능 구현을 하고 PR하는 식이 많기 때문에 이러한 요구사항이 존재했던 것이 아닌가 싶습니다!

PR을 한 번 작성했다면 닫지 말고 추가 커밋을 한다. (3점)

PR을 한 후에 수정 사항이 생기는 경우에는 어떻게 해야 할까요? PR을 닫고 새롭게 열어야 하나 하는 고민을 하는 분들도 오픈채팅방에 많이 계셨습니다.

이번에는 다행히 제출 후에 수정을 하지 않았지만, 만약에 하게 되는 경우에도 PR을 닫지 말고 추가 커밋을 하게 되면 자동으로 반영이 된다고 합니다.

몰랐던 부분이기 때문에, 3점을 주었습니다.

이름을 통해 의도를 드러낸다. (3점)

다른 개발자들과 소통을 잘 하기 위한 가장 좋은 방법 중 하나가 바로 이름을 잘 짓는 연습을 하는 것이라고 합니다.

변수명, 메소드명, 클래스명 등 각 기능에 잘 부합하고, 한 번에 알아볼 수 있도록 잘 작명해야할 것 같습니다. 이 부분에 시간을 많이 써서 연습해도 좋을 것 같습니다.

소통이 잘 되는 개발자를 희망하고 있기 때문에 이 부분을 잘 캐치하여 노력해볼 생각입니다!

축약하지 않는다. (4점)

간결한 코드를 누구나 지향하기 때문에, 이름까지 간결하게 만들어버리고 싶은 충동에 들곤 합니다.

물론 간결하면서 가독성이 좋고 뜻까지 알아채기 쉽다면 최고이겠지만, 그 둘은 보통 상충하는 경우가 많습니다.

그렇기에 우선은 네이밍을 할 시에 굳이 줄여쓰거나 짧게 쓰려 하지말고 그대로 쓰는 연습을 하면 좋을 것 같습니다.

저도 이번에 최대한 알아보기 쉽도록 작명을 하였지만, 아직 부족한 부분이 많은 것 같습니다.

공백도 코딩 컨벤션이다. (2점)

요구사항 중에서 자바 컨벤션을 준수해보라는 말이 있었습니다.

사실 이번에는 정말 간단한 컨벤션만 지키고 구체적으로는 지키지 못한 것 같습니다.

정말 세세한 부분까지 컨벤션이 있기 때문에, 이번에는 코드를 짜기 전에 여러 번 보고 최대한 고려하여 짜면 좋을 것 같습니다.

막상 구현을 할 때는 시간이 오래 걸리지 않으니, 그 이전에 설계와 네이밍, 그리고 컨벤션에 대한 많은 고민을 진행해보아야겠습니다.

공백 라인을 의미있게 사용한다. (3점)

이 또한 위와 비슷합니다. 공백을 의미있게 사용하는 것도 중요하다고 합니다.

문맥을 분리하는 곳에 사용하는 것이 좋으며, 너무 과도한 사용을 지양한다고 합니다.

스페이스와 탭을 혼용하지 않는다. (1점)

많이 찔린 부분이었습니다. 왜냐하면 제 코드리뷰 중에서 들여쓰기가 잘못된 부분을 발견했기 때문입니다.

이러한 부분은 정말 기본적인 것이기 때문에 다음부터 실수해서는 안될 것 같습니다. 마지막으로 다시 한 번 꼼꼼하게 제 코드를 확인하고 제출하는 습관을 들여야겠습니다.

이는 피드백 중에 있었던 IDE 자동 정렬 기능을 이용한다.를 접목하면 좋을 것 같습니다.

인텔리제이에서 Ctrl + Alt + L을 사용해야겠습니다.

의미 없는 주석을 달지 않는다. (4점)

평소에는 주석을 자주 달려고 했었는데, 이번에는 메소드 명을 더 정확하게 적으면서 주석을 줄이려는 노력을 했습니다.

이러한 점은 잘한 것으로 보이고, 앞으로도 그러기 위해서 더 노력하면 좋을 것 같습니다.

Java에서 제공하는 API를 적극 활용한다. (5점)

제공하는 내장 메소드 split join 등을 잘 사용하면 되겠습니다.

이렇게 존재하는 메소드들을 잘 쓰는 것도 실력이라 생각합니다.

배열 대신 Java Collection을 사용한다. (5점)

배열도 좋지만, List, Set, Map 등을 사용하면 더욱 효율적인 코드를 짤 수 있습니다.

결론적으로 자료구조를 잘 활용하면 됩니다.

💡 PR 리뷰

외부 라이브러리 클래스인 console 라이브러리의 readline도 변경이 가능하다. 입력받는 기능을 라이브러리에만 의존하지말고 스스로 추상화해보는 노력도 필요!
입출력하는 경우도 클래스와 메소드로 분리하여 관리하자. 추가로, 1주차 미션 요구사항에서 Hint라고 정의했기 때문에 공통적인 이해배경이 될 수 있도록 Hint라는 용어를 사용하는 것이 좋다.
예외 메세지를 자세하게 작성하자. 어떤 입력값이 들어와서 예외가 발생하는지도 함께 던져주면, 사용자에게 좋을 것 같다.
enum, 상수를 final로 관리하는 법 등을 공부해 적용하면 좋을 것 같다.
메세지를 출력해주는 부분도 각 메소드로 나누어서 구현해보자.
임포트해서 사용할 수 있는 것들은 해서 가독성을 높여보자.
들여쓰기 오류가 있다. 잘 확인하자.
이번에는 flag 변수를 많이 생성했었는데, 굳이 그럴 필요가 없이 리턴값에 넣어줄 수도 있다.