1-1. 1Probem / h x 1h/day x 3days/week 을 기본으로 한다.
1-2. 단 탄력근무제로, 3Problems/week이면 인정
2.1. 독립된 브랜치 사용: 각 구성원은 독립된 브랜치를 가지며, 본인의 브랜치만 수정합니다.
2.2. main 브랜치 공유: 각 구성원의 브랜치는 main 브랜치에서 분기됩니다.
2-3. 커밋 메시지 양식 :
git commit -m "Leetcode, [문제 번호]. [문제 이름]
- [풀이방법 / 알고리즘]
- [코드 리뷰 요청] (optional)
- [추가적인 설명 (ex 시간, 공간 복잡도)] (optional, 권장)"
2.4. 가독성을 위한 폴더 구성: 각 문제에 대한 코드를 별도 폴더에 저장하며,
디렉토리 이름은 "[사이트이름]-[문제 번호]-[문제 이름]" 형식을 따릅니다.
3.1. 주간 최소 커밋: 일주일에 최소 3개의 커밋이 푸시되어야 합니다.
3.2. 벌금 부과: 할당량을 채우지 못한 구성원은 벌금 5,000원을 나머지 구성원에게 분배합니다.
3.3. 휴식기: 시험 첫 날로부터 2주 전부터 시험이 끝난 주까지는 휴식기로 합니다.
4.1. 자유로운 코드 공유: 코드 리뷰 요청이 없더라도 구성원들은 서로의 코드를 자유롭게 확인하고 논의할 수 있습니다.
4.2. 프로페셔널한 코드리뷰: 코드리뷰는 상호 존중과 이성적인 말투를 유지하여 프로페셔널하게 진행합니다.
5.1. 자유로운 가입: 구성원의 반대가 없다면 자유롭게 가입할 수 있습니다.
5.2. 탈퇴시 벌금: 탈퇴 시 구성원들의 인정을 받지 못한 경우, 탈퇴자는 벌금의 10배를 지불합니다.
6.1. 규칙 수정 가능: 규칙은 얼마든지 협의를 통해 수정할 수 있습니다.
6.2. 전체 팀원의 합의: 규칙 수정은 전체 팀원들의 합의를 거쳐야 합니다.
-
문제 이해: 문제를 꼼꼼히 읽고 이해하는 것이 중요합니다. 문제를 정확하게 이해하지 못하면 올바른 접근 방법을 찾기 어려울 수 있습니다.
-
예시와 극단적인 경우 확인: 문제를 이해한 후, 간단한 예시를 통해 문제의 요구사항과 입력에 대한 기댓값을 확인합니다. 또한 극단적인 경우나 제한 조건이 있는 경우를 고려해봅니다.
-
입출력 정의: 문제에서 요구하는 입력과 출력을 정의합니다. 어떤 데이터 구조를 사용할지 결정하고, 문제의 입력과 출력을 어떻게 매핑할지 생각합니다.
-
문제 해결 방법: 문제를 푸는 전략과 알고리즘을 생각합니다. 가장 적절한 알고리즘을 선택하는 것이 중요합니다.
-
의사 코드(Pseudocode) 작성: 선택한 알고리즘에 따라서 간단한 의사 코드를 작성합니다. 의사 코드는 실제 코드가 아니라 알고리즘의 논리를 간단하게 설명하는 코드입니다.
-
실제 코드 작성: 의사 코드를 기반으로 실제 코드를 작성합니다. 문제를 해결하기 위한 자료 구조와 함수를 정의하고, 알고리즘을 구현합니다.
-
테스트와 디버깅: 작성한 코드를 여러 예시로 테스트하여 정확성을 확인합니다. 특히, 경계 조건과 예외 상황을 테스트하는 것이 중요합니다.
-
시간 복잡도와 최적화: 문제를 해결하는 코드의 시간 복잡도를 분석하고, 더 효율적인 최적화 방법을 고려합니다.
-
다른 접근 방법 고려: 한 가지 방법으로 문제를 풀지 못하는 경우 다른 접근 방법을 고려합니다.
-
코드 리팩토링: 최종적으로 문제를 풀었다면, 코드를 보다 깔끔하고 읽기 쉽게 리팩토링합니다.
-
다른 사람의 코드 확인: 문제를 풀었더라도 다른 사람들의 코드를 확인하고 비교해보는 것은 도움이 됩니다.