[우아한 테크 캠프 Pro] 숫자 야구 피드백(프리코스 1주차 - 피드백)

백마금편·2022년 5월 2일
1
post-thumbnail
post-custom-banner

우아한 테크 캠프 프리코스 1주차 피드백

2주차 과제와 함께 1주차 피드백 관련 문서도 같이 왔다.
1주차 피드백 문서에는 1주차 관련 강의와 미션 진행하면서 공통 피드백이 같이 왔다.

강의 내용

해당 강의는 직접 TDD 개발방식으로 1주차 주요기능을 코딩하면서 설명해주는 강의였다.

Production CodeTest Code

public class Calculator {
	
	// Production Code
	int add(int i, int j) {
		return i + j;
	}
	
	int subtract(int i, int j) {
		return i - j;
	}
	
	int multiply(int i, int j) {
		return i * j;
	}
	
	int divide(int i, int j) {
		return i / j;
	}
	
	// Test Code
	public static void main(String[] args) {
		Calculator cal = new Calculator();
		System.out.println(cal.add(3, 4));
		System.out.println(cal.subtract(5, 4));
		System.out.println(cal.multiply(2, 6));
		System.out.println(cal.divide(8, 4));
	}

}

TDD = TFD(Test First Development) + 리팩토링
TDD : Test Code 구현 ➡ 기능 구현 ➡ 리팩토링

TDD Cycle

TDD Cycle
1. Test Fails(실패하는 테스트를 구현한다.)
2. Test passes(테스트가 성공하도록 프로덕션 코드를 구현한다.)
3. Refactoring(프로덕션 코드와 테스트 코드를 리팩토링 한다.)

TDD를 잘하기 위해서는 To-do List를 잘 정리해야한다. == 요구사항 분석을 잘 해야한다.

공통 피드백

이름을 통해 의도를 드러내라.

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

그 동안 코딩하면서 num1, num2 등 변수 이름, Student s = new Student() 등 이름을 너무 대충 지은거 같다.


축약하지 마라.

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

짧고 깔끔한 코드가 보기도 좋고 좋은 코드라고 생각했는데 이 항목을 보면서 그 동안 내가 보기엔 깔끔한 코드였지만 다른 개발자가 보기엔 별로 좋지 않은 코드라고 생각할거 같았다.


개발 도구의 code format 기능을 활용해라.

IntelliJ 또는 Eclipse의 formatting 기능을 활용한다.(Google Java Style Guide 적용하기)

IntelliJ 단축키는 Ctrl+Alt+L(윈도우), Cmd+Alt+L(mac)
Eclipse 단축키는 Ctrl+Shift+F(윈도우), Cmd+Shift+F(mac)


space(공백)도 convention(협약)이다.

for, while, if문 사이의 space도 convention이다.

for (int index = 0; index < list.size(); index++) {
    ...
}

while (true) {
    ...
}

if (true) {
    ...
}

불필요하게 공백 라인을 만들지 않는다.

공백 라인을 뛰우는 것도 코드상에 문맥이 달라지는 부분에 의도를 가지고 뛰우면 좋겠다.

class Student {
	// 변수
    String studentNo;
    String name;
    // 공백(BLANK LINE)
    // 생성자
    Student(String name, String studentNo) {
    	...
    }
}

구현 순서도 convention이다.

클래스의 구현 순서에 대한 convention을 지키는 것도 읽기 좋은 코드를 구현하는데 의미가 있다.

// 상수 -> 클래스 변수 -> 인스턴스 변수 -> 생성자 -> 메소드
class Student {
	// 상수
    static final int MIN_GRADE = 1;
    static final int MAX_GRADE = 3;
    
    // 클래스 변수
    static String schoolName;
    
    // 인스턴스 변수
    String studentNo;
    String name;
    
    // 생성자
    Student(String name, String studentNo) {
    	...
    }
    
    // 메소드
    public void setName() {
        ...
    }
}

반복하지 마라.

중복은 소프트웨어에서 모든 악의 근원이다.

중복은 함수로 처리


space vs tab 혼용 하지 마라.

들여쓰기에 space와 tab을 혼용하지 않는다. 둘 중에 하나만 사용한다.


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

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


값을 하드코딩하지 마라.

문자열 숫자 등의 값을 하드코딩하지 마라.
상수를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내라.

class Student {
    static final int MIN_GRADE = 1;
    static final int MAX_GRADE = 3;
    
    int grade;
    
    Stduent(int grade) {
        if (MIN_GRADE > grade || MAX_GRADE < grade) {
            throw new exception("[Error] grade range");
        }
    }

}

git commit 메시지를 의미있게 작성

commit 메시지에 해당 commit에서 작업한 내용에 대한 이해가 가능하도록 작성한다.


기능 목록 업데이트한다.

README.md 파일에 작성하는 기능 목록은 기능 구현을 하면서 변경될 수 있다.
시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 가지기 보다 기능을 구현하면서 문서를 계속 업데이트한다.


기능 목록 구현을 재검토한다.

기능 목록을 클래스 설계와 구현, 함수 설계와 구현과 같이 너무 상세하게 작성하지 않는다.
클래스 이름, 함수(메소드) input/output은 언제든지 변경될 수 있기 때문이다.
너무 세세한 부분까지 정리하기 보다 구현해야할 기능 목록을 정리하는데 집중한다.
정상적인 경우도 중요하지만 예외적인 상황도 기능 목록에 정리한다.
특히 예외 상황은 시작단계에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해 나간다.


READEME.md를 상세히 작성한다.

README.md는 소스코드에 앞서 해당 프로젝트가 어떠한 프로젝트인지 마크다운으로 작성하여 소개하는 문서이다.
해당 프로젝트가 어떠한 프로젝트이며, 어떤 기능을 담고 있는지 기술해야 한다.

프리코스 1주차 피드백 후기

TDD 강의와 1주 차 과제를 TDD로 개발하는 과정을 지켜보고 나서 TDD에 대한 기본적으로 이해를 하게 되었다.
피드백 강의를 들으면서 처음부터 어렵게 하지 말고 쉬운 기능부터 해보라고 말씀하셨고, 정 어려우면 먼저 개발하고 코드를 삭제하고 TDD 방식으로 다시 개발해보라고 하셨다.
이미 과제를 제출 후여서 해당 강의 내용이 이해가 쉬웠던 거 같다.
앞으로 새로운 기술 및 지식을 공부할 때 급하게 하지 말고 돌아가더라도 이해해야 한다고 생각 들었다.
또한, 공통 피드백 내용은 공감이 많이 갔다.
반복하지 마라., 불필요하게 공백 라인을 만들지 않는다. 같은 내용은 평소에 나름 프로젝트 품질을 높이기 위해 노력했다고 생각하는데 많이 놓쳤던 부분이였다.
위의 내용 중 이해 안가는 부분이 있어 찾아보니 Clean Code에 적혀져 있는 내용 같았다.
나중에 시간이 되면 해당 책을 읽어봐야겠다.

profile
뭐 어떻게 잘 되겠지
post-custom-banner

0개의 댓글