1주 차 피드백

1주 차 미션의 학습 목표는 개발 환경과 프로그래밍 언어에 익숙해지는 것이었습니다. 우아한테크코스가 어떻게 진행되는지 맛볼 수 있도록 과제를 내주겠다고 말씀드렸는데, 여러분은 어땠을지 궁금합니다.

프로그래밍을 처음 접하고 아직 개발 환경이 낯설게 느껴지는 분들을 위해 우아한테크코스의 테코톡 동영상을 공통 피드백에 첨부합니다. 테코톡은 우아한테크코스 크루들이 관심 있는 기술 주제를 스스로 공부하고 공유하는 문화인데요. 앞으로 미션을 수행하면서 어려운 점이 있다면 테코톡을 통해 학습하고 구현해 보는 것을 추천합니다.

우아한테크코스에서는 '완벽하게 해내는 것'보다 '새로운 시도를 멈추지 않는 것'을 더 중요하게 생각합니다.
도전은 단순히 어려운 문제를 푸는 행위가 아니라, 자신이 아직 모르는 영역에 한 발 더 내딛는 태도입니다.

미션을 수행하다 보면 예상치 못한 오류나 막히는 순간을 여러 번 겪게 될 것입니다.
그럴 때 포기하지 않고 문제를 끝까지 탐색해 보는 경험이 바로 성장의 출발점입니다.
하지만 얼마나 탐색해야할지, 얼마나 도전해야할지 막연할 수 있습니다. 그래서 작은 도전부터 시작해 보세요.

예를 들어 이런 작은 도전을 해볼 수 있습니다.

• 아직 익숙하지 않은 메서드나 문법을 하나 골라 적용해서 리팩터링해보기
• 에러를 만나면 바로 검색하지 말고 5분간 스스로 원인을 추측해 보기
• 디스코드에 ‘오늘 처음 시도한 것’ 한 줄 남기기

우테코는 여러분이 "할 수 있는 것만 하는 사람"이 아니라, "해본 적 없던 일에도 하나씩 도전하는 사람"이 되길 기대합니다.

공통 피드백

요구 사항을 정확하게 준수한다

과제를 제출하기 전에 과제 진행 요구 사항, 기능 요구 사항, 프로그래밍 요구 사항을 모두 충족하였는지 다시 한번 확인한다. 이러한 요구 사항들은 미션마다 다르므로 항상 주의 깊게 읽어 본다.

기본적인 Git 명령어를 숙지한다

Git은 개발자 간의 협업을 위한 가장 기본적인 프로그램으로, 컴퓨터 파일의 변경 사항을 추적하고 여러 사용자 간의 해당 파일에 대한 작업을 조정한다. 지금은 add, commit, push 등의 간단한 명령어만 배워도 충분하지만, Git에 대해 미리 알아두어도 나쁠 것은 없다.

• [10분 깃코톡] 와일더의 Git Commands
• [10분 테코톡] 주노의 git commands
• [10분 테코톡] 망쵸의 유용한 Git 명령어
• [10분 테코톡] 해시, 다르의 깃 명령어 동작 원리

Git으로 관리할 자원을 고려한다

Java 코드만 있으면 .class 파일을 생성할 수 있다. 따라서 Git을 통해 .class 파일을 관리할 필요가 없다. IntelliJ IDEA의 .idea 폴더와 Eclipse의 .metadata 폴더도 IDE에서 자동으로 생성하는 폴더이므로 Git으로 관리할 필요가 없다. Git에 코드를 추가할 때는 Git을 통해 형상 관리해야 하는 코드인지 고려하는 것이 좋다. 또한 .gitignore에 대해서도 알아본다.

커밋 메시지를 의미 있게 작성한다

해당 커밋에서 수행된 작업을 이해할 수 있도록 커밋 메시지를 작성한다. 또한 팀의 좋은 코드 리뷰 문화는 작은 커밋을 작성하는 것에서 비롯된다.

• 좋은 git 커밋 메시지를 작성하기 위한 7가지 약속

커밋 메시지에 이슈 또는 풀 리퀘스트 번호를 포함하지 않는다

일부 프로젝트에서는 작업을 이슈 또는 풀 리퀘스트와 연결하기 위해 커밋 메시지에 이슈 또는 풀 리퀘스트 번호를 포함하기도 한다. 그러나 이 접근 방식은 원본 저장소의 관련 없는 이슈 또는 풀 리퀘스트에 영향을 미칠 수 있다. 따라서 이 과정에서는 커밋 메시지에 이슈 또는 풀 리퀘스트 번호를 포함하지 않는다.

풀 리퀘스트를 만든 후에는 닫지 말고 추가 커밋을 한다

이미 풀 리퀘스트를 생성하면 변경을 위해 새 풀 리퀘스트를 만들 필요가 없다. 변경이 필요한 경우 추가 커밋을 하면 자동으로 반영된다. 그러므로 미션 제출 기간 이후에는 추가 커밋을 금지한다.

오류를 찾을 때 출력 함수 대신 디버거를 사용한다

디버깅은 프로그램 오류를 감지하고 수정하는 과정이다. 문법 오류와 같이 컴파일러가 처리하기 때문에 쉽게 발견할 수 있는 오류도 있지만, 어느 지점에서 오류가 발생했는지 파악하기 어려운 경우도 있다. 이때 코드 중간에 System.out.println()를 사용하여 매번 코드를 실행하여 문제를 파악할 수 있으나, 이는 비효율적이며 불필요한 코드가 남을 수 있다. 하지만 디버거를 이용하면 코드 내부의 상태 값이 어떻게 변하는지, 어떤 흐름으로 프로그램이 실행되는지 이해할 수 있다. 현재 사용 중인 IDE에서 애플리케이션을 디버깅하는 방법을 학습한다.

• [10분 테코톡] 웨지의 인텔리제이 디버깅
• [10분 테코톡] 오리의 Intellij Debugging
• [10분 테코톡] 몰리의 디버깅
• Debugging in Visual Studio Code

이름을 통해 의도를 드러낸다

나 자신, 다른 개발자와의 소통을 위해 중요한 활동 중의 하나가 좋은 이름 짓기이다. 변수 이름, 함수(메서드) 이름, 클래스 이름을 짓는데 시간을 투자하라. 이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내기 위해 노력하라. 연속된 숫자를 덧붙이거나(a1, a2, ..., aN), 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.

축약하지 않는다

의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.

누구나 실은 클래스, 메서드, 또는 변수의 이름을 줄이려는 유혹에 곧잘 빠지곤 한다. 그런 유혹을 뿌리쳐라. 축약은 혼란을 야기하며, 더 큰 문제를 숨기는 경향이 있다. 클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제하자. 클래스 이름이 Order라면 shipOrder라고 메서드 이름을 지을 필요가 없다. 짧게 ship이라고 하면 클라이언트에서는 order.ship()라고 호출하며, 간결한 호출의 표현이 된다.

• 객체 지향 생활 체조 원칙 5: 줄여쓰지 않는다(축약 금지)

공백도 코딩 컨벤션이다

if, for, while문 사이의 공백도 코딩 컨벤션이다.

공백 라인을 의미 있게 사용한다

공백 라인을 의미 있게 사용하는 것이 좋아 보이며, 문맥을 분리하는 부분에 사용하는 것이 좋다. 과도한 공백은 다른 개발자에게 의문을 줄 수 있다.

스페이스와 탭을 혼용하지 않는다

들여쓰기에 스페이스(space)와 탭(tab)을 혼용하지 않는다. 둘 중의 하나만 사용한다. 확신이 서지 않으면 풀 리퀘스트를 작성한 후 들여쓰기가 잘 되어 있는지 확인하는 습관을 들인다.

의미 없는 주석을 달지 않는다

변수 이름, 함수(메서드) 이름을 통해 어떤 의도인지가 드러난다면 굳이 주석을 달지 않는다. 모든 변수와 함수에 주석을 달기보다 가능하면 이름을 통해 의도를 드러내고, 의도를 드러내기 힘든 경우 주석을 다는 연습을 한다.

코드 포매팅을 사용한다

코드 포매팅과 구조화는 클린 코드를 위한 최소한의 요구 사항이다. IDE의 코드 자동 정렬 기능을 사용하면 더 깔끔한 코드를 볼 수 있다.

• IntelliJ IDEA: ⌥⌘L, Ctrl+Alt+L
• Eclipse: ⇧⌘F, Ctrl+Shift+F
• Visual Studio Code: ⇧⌥F, Shift+Alt+F

Java에서 제공하는 API를 적극 활용한다

함수(메서드)를 직접 구현하기 전에 API에서 해당 함수를 제공하는지 확인한다. 예를 들어 사용자를 출력할 때 사용자가 둘 이상인 경우 쉼표(,) 기반 문자열을 출력하도록 다음과 같이 구현할 수 있다.

var members = List.of("pobi", "jason");
var result = String.join(",", members); // pobi,jason

배열 대신 컬렉션을 사용한다

컬렉션(List, Set, Map 등)을 사용하면 다양한 API를 사용하여 데이터를 조작할 수 있다. 예를 들어 List에 "pobi" 값이 있는지 다음과 같이 확인할 수 있다.

var members = List.of("pobi", "jason");
var result = members.contains("pobi"); // true