우아한테크코스 프리코스 1주차를 위한 계획

좋아하는 책 제목이 생각에 관한 생각인데, 내용적인 것 보다는 제목이 기억에 많이 남았었습니다

프로젝트에 대한 계획이 아니라 프로젝트를 설계하는 그 일반적인 과정을 고려하는 과정을 좋아합니다

완성까지는 하지 않더라도 대충 프로세스를 이해할 수 있을 정도까지는 작성해보았습니다

간단한 목표이자 설계 과정

특정 프로젝트가 아닌, 프리코스 프로젝트를 만들 때 필요한 것들을 적고자 합니다

정말 좋은 문제를 미리 해보면서 참여했을 때의 느낌을 잃어버리기 싫어서 완성까지는 가지는 않았습니다

프로젝트의 빡빡한 제약조건을 고려해보고 각 프로젝트를 통해 얻게 하고자 하는 것이 무엇일지 고민해보았습니다

 

좋은 프로젝트란 무엇인가?

1. 다른 사람이 알아보기 쉬운 프로젝트

이 조건을 정말 세심하게 쪼개두었습니다

1. 커밋메시지에 관한 규칙

2. 코드 자체에 대한 규칙

3. 로직에 대한 규칙

대충 감각적으로 알고 있던 내용을 완벽하게 정리해둔 느낌이 들어서 좋았습니다

 

1. 커밋 메시지에 대한 규칙

커밋 메시지만으로 다른 사람이 뭘 했던 것인지를 파악할 수 있어야 합니다

AngularJS 팀의 커밋 규칙을 따라 갑니다 

실제 AngularJS의 레포를 구경하러 갔다 왔습니다

물론 오픈소스이기에 누구나 참여할 수 있어서 완벽한 커밋 로그만 남아있는 것은 아니었습니다

그럼에도 적어도 대부분의 경우에 커밋 로그를 깔끔하게 남기는 것을 확인할 수 있었습니다

직접 효과를 보고 나니 더욱 명확했습니다 

 

2. 코드 자체에 대한 규칙

코드를 일관성있게 유지해라

hackday-convention-java 의 규칙을 통해서 예상할 수 있는 코드를 만들어라

이 부분은 로직에 관련되지 않고 순수하게 변수나, 포맷에만 관련이 있는 규칙이고, 제약입니다 

변수명은 이렇게 짓고, 개행문자는 어떻고, tab은 어떻고 하는 내용을 담고 있습니다

 

3. 로직에 대한 규칙

클래스는 최대한 작게, 메서드는 작게 분리해서 자기만의 책임을 명확하게 할 수 있어야 한다

 indent는 최대 2까지로 한다

객체지향 생활 체조 9가지를 통해서 보면 됩니다

테크코스에 있는 내용보다 조금 더 빡빡한 제약이지만, 객체지향적이고, 좋은 규칙을 볼 수 있습니다

 

만들기 위한 프로세스를 미리 생각해보자

1. fork를 통해 프로젝트를 가져온다

그냥 버튼 누르면 끝

 

2. 초기 환경 세팅을 추가한다

gitattribute나, tabwidth같은 세팅들을 추가한다

 

3. README.md 를 기능 중심으로 작성한다

3.1 연습할 때는 시퀀스 다이어그램을 만들어서 객체 지향 설계를 연습한다

 

4. 기능 단위로 커밋한다

코드를 객체지향 생활체조 9가지 원칙에서 빡빡하게 보고 시작한다

커밋 메시지를 잘 신경쓴다

 

5. 기능에 단위 테스트를 추가한다

Jupitor를 통해서 테스팅을 할 수 있다는 것을 과거 자료를 통해서 확인할 수 있었기에 테스팅 하는 연습을 해야 할 것

도메인 별로 깔끔하게 작성할 수 있도록 연습해야 한다

 

4.5를 반복한다 Readme.md를 중간중간 수정한다

Readme.md는 살아있는 문서여야 한다

계속해서 Readme.md를 보충하자

 

사전에 할 수 있는 일들

1. 초기 환경 세팅에 대해서 gitattribute나, 추가해야 할 것들을 미리 알아볼 수 있다

2. AngularJS 팀의 커밋 규칙을 학습한다

3. 오브젝트를 읽고, 예제 코드를 보면서 객체지향 설계를 연습한다

4. Jupitor 사용법을 익힐 수 있다

5. 예전 과정의 피드백들을 미리 읽어보고 체크리스트를 만들 수 있다

6. 클린 코드에 나오는 중요한 개념들을 학습할 수 있다

 

체크리스트

1) 변수, 함수, 클래스 이름에서 충분히 의도가 드러나는가?
2) 변수, 함수, 클래스 이름을 축약하진 않았는가?
3) Eclipse에서 "ctrl + shift + F" 로 정리 했는가?
4) 불필요한 space 혹은 enter line은 없는가?
5) 비슷한 코드가 반복되지는 않는가?
6) space와 tab을 혼용하진 않았는가?
7) 의미없이 주석을 달진 않았는가? (정말 의도가 드러나기 힘든 경우에만 작성)
8) 하드코딩을 하진 않았는가? (상수, Enum으로 대체)
9) git commit 메세지를 의미있게 작성했는가? (기능 단위로 이해 되도록)
10) 기능 목록을 너무 상세하게 메소드와 클래스 단위로 작성하진 않았는가?
11) 인스턴스 멤버를 선언할 때 순서에 맞게 하였는가? (상수 -> 필드 -> 생성자 -> 메소드)
12) 배열 대신 Collection을 사용하고, API를 많이 활용하였는가?
13) getter/setter를 사용하진 않았는가?
14) 인스턴스 필드의 수가 3개 이상이 되진 않았는가?
15) 인코딩을 UTF-8로 하였는가?
16) main 메소드를 포함한 모든 메소드가 각각 15라인 보다 많진 않은가? (10라인 이하가 베스트)
17) 예외 처리는 모두 고려하였는가? (정말 꼼꼼하게 예외 상황의 모든 경우를 생각해보아야 한다.)
18) Pull Request 보내기 전에 혹시 master 브랜치로 되어있는거 아닌지 확인했는가?
19) 상황에 맞는 설계와 구현 방법을 택했는가? (정답 보다는 요구사항에 적합한 설계와 구현인가?)
20) 반복문을 너무 남용하지는 않았는가? (재귀 함수로도 충분히 가능하다)
21) 원시 타입과 문자열을 포장하였는가?
22) 자료구조의 쓰임을 정확히 이해하였는가? (Set을 쓰는 것이 낫다면 List가 아니라 정확히 Set을 써야한다.)
23) 함수가 한 가지 일만 하고 있는가?
24) 함수를 최대한 작게 만들었는가?
25) indent를 최대 2까지 허용하였는가? (최대 1이 베스트)
26) 삼항 연산자를 사용하진 않았는가?
27) else 예약어를 사용하진 않았는가?
28) 한줄에 점 하나만 찍었는가?
29) 일급 컬렉션의 형태로 작성하였는가?
30) 비지니스 로직과 UI 로직을 한 클래스가 담당하지 않도록 한다.

라는 내용들이 과거에 있던 피드백을 정리했던 분의 정리입니다

당연히 이 부분을 최대한 활용하긴 할 거지만, 저만의 목록을 작성할 수 있도록 노력해보겠습니다