[우아한 테크코스] 프리코스 1주차 회고

🍀 들어가기에 앞서서..

 

들어가기에 앞서, 우선 우테코 측에서 제공한 docs 를 확인했다.

 

1. 코드 컨벤션

우테코 측에서 제공한 xml 파일을 다운로드 받아 intelliJ 내부에서 코드스타일을 적용해주었다. 기존에는 구글 코드스타일로 되어 있어서 약간의 차이점이 있는 우테코 측의 파일을 이용했다.

 

2. 클린 코드를 위한 원칙

🍀 왜 원시값과 문자열을 포장해야 할까?

1. 자신의 상태를 객체 스스로 관리할 수 있다.

- User 이라는 객체 안에 원시형(int)인 age 가 있다고 가정해보자. 이를 Age 라는 클래스로 포장하지 않고 원시 타입 그대로 갖고 있게 된다면, age 에 대한 유효성 검사를 User 클래스 내부에서 해야 한다. 그러나, Age 라는 클래스로 포장하게 된다면 User 에서는 더 이상 age 라는 멤버변수에 대한 유효성 검사를 하지 않아도 된다.

2. 코드의 유지보수에 도움이 된다.

- List<Integer> scores라는 매개변수가 있다고 가정해보자. 이를 Score 이라는 클래스로 감싸지 않고 Integer 과 같은 원시 자료형을 사용하게 된다면 이를 매개변수로 받는 클래스에서 개별값을 모두 일일이 관리해줘야 한다. 이는 객체지향적이지 않고 클래스의 크기가 비대하게 커지는 문제를 초래할 수 있다.

3. 자료형에 구애받지 않는다.

- Socre 라는 클래스가 있다고 가정해보자. 처음에는 int  자료형만 필요했지만 추후에 double 자료형 역시 필요해졌다면, 생성자 오버로딩을 통해서 간단하게 해결할 수 있다.

 

https://velog.io/@jhp1115/%EC%9B%90%EC%8B%9C%EA%B0%92%EA%B3%BC-%EB%AC%B8%EC%9E%90%EC%97%B4-%ED%8F%AC%EC%9E%A5

원시값과 문자열 포장

 

🍀 왜 일급 콜렉션을 적용해야 할까?

일급 컬렉션은 컬렉션을 포함한 클래스는 다른 멤버변수가 없어야 한다는 원칙이다.

 

일급 컬렉션을 적용해야 하는 이유는 멤버변수의 상태와 필요한 로직을 수행하는 행위를 일급 컬렉션 클래스에서 한번에 관리하는 것이다. 예를 들어, Coupon 이라는 객체가 있고 이에 대한 컬렉션을 관리해야 한다면 일급 컬렉션을 따로 만들어 관리해야 한다는 것이다.

public class CouponBasket{
	private final List<Coupon> coupons;
}

CouponBasket 이라는 일급컬렉션은 멤버변수로 컬렉션을 제외한 멤버변수를 갖지 않는다. 

또한, 일급 컬렉션을 사용하면 immutable object 가 될 수 있다.

 

---

 

특히 유념하면서 진행한 부분

- 최대한 클린코드를 지향하며 짤 것

- 함부로 커밋하지 않을 것

- 하나의 메소드는 반드시 한 가지의 일만 담당하도록 할 것

- 메서드명을 허투로 짓지 않기

 

다음 링크 세개를 계속해서 참고하고자 노력했다.

https://github.com/woowacourse/woowacourse-docs/blob/main/cleancode/pr_checklist.md

GitHub - woowacourse/woowacourse-docs: 우아한테크코스 문서를 관리하는 저장소

https://thalals.tistory.com/325

1. 자바 네이밍 규칙 (java 네이밍 컨벤션)

https://tecoble.techcourse.co.kr/post/2020-04-26-Method-Naming/

좋은 코드를 위한 자바 메서드 네이밍

 

🍀 고민했던 지점들

 

#커밋메시지

처음에는 이제까지 늘 해왔던 대로

<커밋 타입:커밋메시지> 로 했었다. 그러나 이렇게 하니 생겼던 문제점은

 

1. 문제가 여러개이다보니 비슷한 커밋 메시지가 많이 생길 것

2. 어떤 문제에 대한 커밋인지 명확하지 않음

 

이 있었다. 그래서 슬랙에서 어떤 분이 보내주신 아래 링크를 참고하여 괄호를 사용해보려고 했다.

 

https://html-jc.tistory.com/457?category=946831 

[우테콘2022] 우리 팀의 코드리뷰 문화, 이렇게 조금씩 발전했어요 - (3) 코드리뷰 문화, 이렇게 개

 

내가 선택한 커밋 메시지의 방식은 <커밋타입(problem 문제번호):커밋 메시지> 였다. 또한 최대한 커밋 메시지도 문제별로 통일하고자 노력했다.

 

#기능 구현 사항 정리

 

기능 구현 사항을 정리해야 할 때 처음에는 많이 헷갈리고 습관처럼 코드를 짜다가 '아 맞다! 기능 구현 사항 정리해야지' 하는 생각을 하게 됐다. 그러나 몇번 반복해보니 어느 정도의 루틴이 잡혔다.

또한 problem1~6까지는 모두 기능을 모호하게 정리해두었었다. 그러나 problem 7에 와서 든 생각이 메서드명까지 미리 생각해두면 명확하겠다 하는 것이었다. 그래서 그 이후로는 마지막 문제인 problem7에서는 메서드명까지 미리 정해두었다. 이렇게 하니 메서드명에 대해서 더 깊이 고민하게 되고, 기능 구현을 쪼개는 단위도 명확하게 기준이 정립되는 느낌이었다. 

 

# 공통

List 를 써야 할까 Array 를 써야 할까 의문이 들고 헷갈려서 나름대로의 기준을 정해야겠다고 생각했다.

 

Array - 길이를 바꿀 수 없음. 메모리 관리에 이점. - 인덱스를 통한 접근이 용이 - 삽입/삭제에 불리

List - 삽입/삭제가 용이 - 메모리 재사용이 편리 - 불연속적 - 검색의 성능이 좋지 않음 - 추가적인 메모리 공간의 발생 (포인터를 사용해서)

 

메모리가 고정되고 업데이트나 삭제가 없으며 인덱스를 통한 접근만 이루어지는 경우에는 Array를 사용하고,

인덱스가 아니라 요소가 포함되어있는지 확인해야 하는 경우, 업데이트나 삭제가 빈번한 경우에는 List 를 써야겠다고 나름의 기준을 정립했다.

 

---

 

🍀 클린코드 체크리스트

1. 한 메서드에 오직 한 단계의 들여쓰기만 허용했는가?

2. else 예약어를 쓰지 않았는가?

3. 모든 원시값과 문자열을 포장했는가?

4. 콜렉션에 대해 일급 콜렉션을 적용했는가?

5. 3개 이상의 인스턴스 변수를 가진 클래스를 구현하지 않았는가?

6. getter / setter 없이 구현했는가?

7. 메소드의 인자 수를 제한했는가?

8. 코드 한 줄에 점을 하나만 허용했는가?

9. 메소드가 한 가지 일만 담당하도록 구현했는가?

10. 클래스를 작게 유지하기 위해 노력했는가?

 

---

🍀 Problem 1

🧙🏻 코드를 구현하면서 고려했던 점

1. 예외사항을 판단하는 클래스의 메서드들을 정적으로 둘 것인가 아닌가 -> 해당 클래스 추후에 삭제함

어떤 경우에 정적 메서드를 활용하는지 확인해보았다.

• 유틸리티 클래스로 작성되고 변화를 가정하지 않음
• 인스턴스 변수를 사용하지 않음
• 인스턴스 생성에 의존하지 않음
• 변화되지 않고 오버라이딩 되지 않음

유효성 검사 클래스는 인스턴스로 생성될 이유가 없고, 변화될 이유도 없고, 오버라이딩 할 지점도 없기 때문에 정적 메서드로 선언해야 한다는 판단을 내렸다. 따라서 정적 메서드로 선언해주었다.

 

2. 점수 계산을 어디서 해야 할까

problem 내부? 따로 빼야 할까?

 

최대한 Problem1 클래스 자체를 가볍게 가져가고 싶었다. 해당 클래스에서는 책의 페이지를 받고, 승자를 판단하는 기능만 했으면 좋겠다고 생각했다. 왜냐하면 점수를 계산하면서 따져야 할 부분들이 존재해 코드가 길어지고 있었기 때문이다. 

따라서 Calculator 라는 클래스를 두고, 해당 클래스 내에서 pobi 와 crong 의 점수 계산을 각각 할 수 있도록 했다.

 

🧙🏻 리팩토링 과정에서 고려했던 점

+ 리팩토링을 하던 과정에서, Calculator 클래스와 유효성을 검사하던 InputException 이라는 클래스를 삭제하고 Score 이라는 클래스를 생성해 생성자를 통해 유효성 검사를 할 수 있도록 했다. 이렇게 사고하게 된 과정은 다음 글을 참고해서이다. 비록, 해당 글은 일급 컬렉션과 관련되어 있지만, 다음글을 보며 생성자를 통해서 유효성을 검사하는 것이 더 효율적일 것이라는 생각이 들었다. 

 

https://velog.io/@bosl95/%E3%85%87%E3%84%B9%E3%84%B4%E3%85%87

자바의 일급 컬렉션

 

이렇게 리팩토링을 거치게 된 계기는

 

1. 클라이언트 코드가 try-catch 형태로 개선될 수 있다.

- 이전에는 InputException 클래스의 static 메서드를 일일이 불러서 if 문을 사용해 유효성 검사를 해야 했다. 그러나 이는 try-catch 문으로 개선될 수 있을 것이라고 생각했다.

 

2. Calculator 의 클래스명

- Calculator 가 계산기라는 뜻으로 생성한 것이었는데, 계산기의 기능을 하려면 pobi 와 crong 의 각각 계산기를 만든다는 의미가 논리적으로 조금 이상하게 생각됐다. 

 

그래서 직관적으로 Score 라는 객체를 생성하고, 이가 유효하지 않은 값이라면 catch 로 넘어가 바로 예외 상황에 해당하는 값을 반환하도록 했고 유효한 값이라면 정상적으로 Score 객체가 생성될 것이기에 클래스 내부에 존재하는 getMaxScore 메서드를 통해 각 참가자의 최고 점수를 불러와 비교할 수 있도록 했다.

🧙🏻 1번의 클린코드 체크리스트

1. 한 메서드에 오직 한 단계의 들여쓰기만 허용했는가?

2. else 예약어를 쓰지 않았는가?

3. 모든 원시값과 문자열을 포장했는가?

4. 콜렉션에 대해 일급 콜렉션을 적용했는가?

5. 3개 이상의 인스턴스 변수를 가진 클래스를 구현하지 않았는가?

6. getter / setter 없이 구현했는가?

7. 메소드의 인자 수를 제한했는가?

8. 코드 한 줄에 점을 하나만 허용했는가?

9. 메소드가 한 가지 일만 담당하도록 구현했는가?

10. 클래스를 작게 유지하기 위해 노력했는가?

1	2	3	4	5	6	7	8	9	10
✅	✅	🧐 ✅	🧐 ✅	✅	✅	✅	✅	✅	✅

- 3번 조건

조금 애매하게 느껴진다.. 만일 하나의 페이지 자체로 유효성 검사가 가능하거나 그 자체로 값을 갖는 것이 의미가 있었다면 Page 라는 클래스를 생성했을텐데 해당 문제 상황을 고려해보면 왼쪽 페이지 오른쪽 페이지를 같이 보면서 유효성 검사와 점수 계산을 해야 해서 Page 라는 객체를 생성하는 것이 의미가 없게 느껴졌다. 그래서 그냥 list 형태 그대로 Score 클래스에 가져와서 사용했는데 이게 최선일지는 확신이 서지 않는다. 

- 4번 조건

앞서 언급한 이유와 비슷하게 pages 라는 List 가 멤버변수로 있어서 고민을 했다. 자꾸만 pages 라는 멤버변수명이 page 라는 객체의 콜렉션인 것 같은 느낌을 줘서 코드가 모호해지는 것 같다고 생각했다.

 

개선

leftPage 와 rightPage 라는 멤버변수를 두어서 관리하는 것으로 변경했다.

개선 이후에는 3,4번 조건도 만족했다고 생각된다.

 

---

🍀 Problem 2

 

🧙🏻 코드를 구현하면서 고려했던 점

1. early continue 사용

private static String decrypt(String cryptogram) {
    Stack<Character> stack = new Stack<>();
    char[] chars = cryptogram.toCharArray();
    char before = ' ';

    for (char c : chars) {
        if (!stack.isEmpty() && stack.peek() == c) {
            stack.pop();
            before = c;
            continue;
        }
        if (c == before) {
            continue;
        }
        stack.push(c);
    }
    return changeStackToString(stack);
}

어떻게 else 를 쓰지 않고 해당 부분을 구현하지 하는 고민이 들었다. 왜냐하면 else 를 쓰지 않고 if 문을 두번 쓰게 되면 두 가지 조건에 다 걸릴 수도 있는 상황이 발견했기 때문이었다. 그래서 continue 를 써도 되나 하는 생각이 들어 찾아보니 early return / early continue 를 권장한다고 하여 해당 방법을 사용했다.

 

🧙🏻 2번의 클린코드 체크리스트

1. 한 메서드에 오직 한 단계의 들여쓰기만 허용했는가?

2. else 예약어를 쓰지 않았는가?

3. 모든 원시값과 문자열을 포장했는가?

4. 콜렉션에 대해 일급 콜렉션을 적용했는가?

5. 3개 이상의 인스턴스 변수를 가진 클래스를 구현하지 않았는가?

6. getter / setter 없이 구현했는가?

7. 메소드의 인자 수를 제한했는가?

8. 코드 한 줄에 점을 하나만 허용했는가?

9. 메소드가 한 가지 일만 담당하도록 구현했는가?

10. 클래스를 작게 유지하기 위해 노력했는가?

1	2	3	4	5	6	7	8	9	10
✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

- 8번 조건

디미터의 법칙이 stream과 같이 . 을 많이 써야 하는 경우에도 강제되는 것인지 궁금해서 찾아봤더니 아니라고 한다. 디미터의 법칙은 캡슐화와 객체의 내부 구조가 유출되지 않는 것이 목적이기에 stream API 는 이를 위배하지 않는다는 것이다.

 

---

🍀 Problem 3

🧙🏻 3번의 클린코드 체크리스트

1. 한 메서드에 오직 한 단계의 들여쓰기만 허용했는가?

2. else 예약어를 쓰지 않았는가?

3. 모든 원시값과 문자열을 포장했는가?

4. 콜렉션에 대해 일급 콜렉션을 적용했는가?

5. 3개 이상의 인스턴스 변수를 가진 클래스를 구현하지 않았는가?

6. getter / setter 없이 구현했는가?

7. 메소드의 인자 수를 제한했는가?

8. 코드 한 줄에 점을 하나만 허용했는가?

9. 메소드가 한 가지 일만 담당하도록 구현했는가?

10. 클래스를 작게 유지하기 위해 노력했는가?

1	2	3	4	5	6	7	8	9	10
✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

---

🍀 Problem 4

🧙🏻 코드를 구현하면서 고려했던 점

1. string buffer 사용

처음에는 단순히 문자열을 더하기 연산으로 붙일까 buffer 를 이용할까 고민했다.

계속 더하기 연산을 하는 것, buffer 를 생성하는 것 중 어떤 것이 더 속도나 메모리 측면에서 효율적인지 고민을 해보았다.

concat 혹은 + 를 사용하게 되면 1000번 이상 사용할 경우 속도가 느려지기 때문에 비효율적인 결과를 낳을 수 있으므로 String Builder 를 사용해야 한다고 했다. 해당 문제의 경우 해석해야 하는 word의 길이가 1~1000이라고 했으므로 아슬아슬하다고 생각해 buffer 를 생성해 사용해주었다.

 

https://wakestand.tistory.com/245

자바 StringBuffer, StringBuilder 개념부터 사용법까지

 

🧙🏻 리팩토링 과정에서 고려했던 점

solution 메서드는 답을 반환하는 정도의 기능만 하는 것을 목표로 잡았기에 solution 메서드에서 반복하던 반복문을 getDecryptedWord 라는 메서드로 빼서 구현했다.

 

🧙🏻 4번의 클린코드 체크리스트

1. 한 메서드에 오직 한 단계의 들여쓰기만 허용했는가?

2. else 예약어를 쓰지 않았는가?

3. 모든 원시값과 문자열을 포장했는가?

4. 콜렉션에 대해 일급 콜렉션을 적용했는가?

5. 3개 이상의 인스턴스 변수를 가진 클래스를 구현하지 않았는가?

6. getter / setter 없이 구현했는가?

7. 메소드의 인자 수를 제한했는가?

8. 코드 한 줄에 점을 하나만 허용했는가?

9. 메소드가 한 가지 일만 담당하도록 구현했는가?

10. 클래스를 작게 유지하기 위해 노력했는가?

1	2	3	4	5	6	7	8	9	10
✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

---

🍀 Problem 5

🧙🏻 코드를 구현하면서 고려했던 점

1. 배열을 반환하는 메서드의 경우 어떻게 메서드명을 지어야 할까

 

다음 링크를 참고하여 getAllCntByUnit 이라고 지었다.

 

https://stackoverflow.com/questions/9340394/best-way-to-name-methods-that-returns-list-of-objects

Best way to name methods that returns list of objects

 

🧙🏻 5번의 클린코드 체크리스트

1. 한 메서드에 오직 한 단계의 들여쓰기만 허용했는가?

2. else 예약어를 쓰지 않았는가?

3. 모든 원시값과 문자열을 포장했는가?

4. 콜렉션에 대해 일급 콜렉션을 적용했는가?

5. 3개 이상의 인스턴스 변수를 가진 클래스를 구현하지 않았는가?

6. getter / setter 없이 구현했는가?

7. 메소드의 인자 수를 제한했는가?

8. 코드 한 줄에 점을 하나만 허용했는가?

9. 메소드가 한 가지 일만 담당하도록 구현했는가?

10. 클래스를 작게 유지하기 위해 노력했는가?

1	2	3	4	5	6	7	8	9	10
✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

---

🍀 Problem 6

🧙🏻 코드를 구현하면서 고려했던 점

 

1. 소유격을 나타내야 하는 경우 어떻게 메서드명을 지어야 할까

 

다음 링크를 참고하여 for 를 사용했다. ex) saveInfoForStudent

https://stackoverflow.com/questions/2034679/how-do-you-work-around-the-need-for-apostrophes-in-certain-function-names

How do you work around the need for apostrophes in certain function names?

🧙🏻 리팩토링 과정에서 고려했던 점

1. 변수명

final 인 변수명을 규칙에 맞게 studentsInfo -> STUDENTS_INFO -> INFO_FOR_STUDENTS 로 바꿨다.

 

🧙🏻 6번의 클린코드 체크리스트

1. 한 메서드에 오직 한 단계의 들여쓰기만 허용했는가?

2. else 예약어를 쓰지 않았는가?

3. 모든 원시값과 문자열을 포장했는가?

4. 콜렉션에 대해 일급 콜렉션을 적용했는가?

5. 3개 이상의 인스턴스 변수를 가진 클래스를 구현하지 않았는가?

6. getter / setter 없이 구현했는가?

7. 메소드의 인자 수를 제한했는가?

8. 코드 한 줄에 점을 하나만 허용했는가?

9. 메소드가 한 가지 일만 담당하도록 구현했는가?

10. 클래스를 작게 유지하기 위해 노력했는가?

1	2	3	4	5	6	7	8	9	10
✅	✅	✅	✅	✅	✅	✅	✅	🧐✅	✅

- 9번 조건

saveInfoForStudent 메서드에서 문자열을 일일이 돌며 (1) 문자열을 자르는 동시에 (2)해당 문자열이 이미 존재하는지 확인하고 (3) 2의 결과에 따라 저장을 하는 기능까지 구현해서 개선해야겠다는 생각을 하게 되었다.

 

개선

Student 클래스를 새로 생성하여 email 과 name 을 저장하고 해당 클래스 내부에서 getSubNames 라는 메서드를 생성해 학생의 부분 문자열들을 반환하는 기능을 구현했다.

 

---

🍀 Problem 7

🧙🏻 코드를 구현하면서 고려했던 점

1. 어떻게 정렬 기준을 정하고 정렬하는 것이 가장 효율적일지

다음 링크를 참고하여 comparator 를 사용했다.

https://st-lab.tistory.com/243

자바 [JAVA] - Comparable 과 Comparator의 이해

2. 어떻게 정렬 기준을 정하고 정렬하는 것이 가장 효율적일지

 

🧙🏻 리팩토링 과정에서 고려했던 점

변수명 / 메서드명을 많이 고민했다. 소유격을 나타내는 by 와 ~에 의해서를 나타내는 by 가 충돌했기 때문이다.

예를 들어서 getRelationshipByUser 은 user 의 관계를 가져오는 메서드이고, getScoresByOverlappedUsers 는 겹치는 사용자에 의하여 점수를 구하는 메서드이기 때문이다. 전자는 ~의 즉 소유격이고 후자는 ~에 의해서를 나타내서 메서드명이 스스로 쓰면서도 헷갈렸다. 그래서 전자는 for / 후자는 by 로 통일했다.

또한, 사용자가 세 가지 종류가 있다고 생각했다.

1. 친구인 사용자

2. 친구가 아닌데 추천친구인 사용자

3. 친구도 아니고 추천친구도 아닌 사용자

그래서 User 로 써야 할지, Friend 로 써야할지 헷갈렸다. 또한 이미 주어진 파라미터 중에 friends 라는 이름도 있어서 더 애매하다고 느꼈다. 

1 번의 경우에는 relationship 이라는 용어를 사용했고, 아직 추천친구일지 아닐지 모르는 사용자들에 대해서는 User, 추천친구를 구하는 경우에는 RecommendedFriend 라는 용어를 사용해서 일관성 있게 가져가기 위해 노력했다.

 

🧙🏻 7번의 클린코드 체크리스트

1. 한 메서드에 오직 한 단계의 들여쓰기만 허용했는가?

2. else 예약어를 쓰지 않았는가?

3. 모든 원시값과 문자열을 포장했는가?

4. 콜렉션에 대해 일급 콜렉션을 적용했는가?

5. 3개 이상의 인스턴스 변수를 가진 클래스를 구현하지 않았는가?

6. getter / setter 없이 구현했는가?

7. 메소드의 인자 수를 제한했는가?

8. 코드 한 줄에 점을 하나만 허용했는가?

9. 메소드가 한 가지 일만 담당하도록 구현했는가?

10. 클래스를 작게 유지하기 위해 노력했는가?

1	2	3	4	5	6	7	8	9	10
✅	✅	✅	✅	🧐	✅	✅	✅	✅	✅

- 5번 조건

현재 User 클래스의 인스턴스 변수가 5개이다 ㅜ.ㅜ 최대한 줄이고자 해보았으나 인스턴스 변수를 일부 걷어낼 경우 코드와 로직이 너무 복잡해져서 어떻게 구상해야 할지 더 고민해봐야겠다..

---

🍀 소감

1. 알고 있었지만..

클린코드를 지향해야 하고, 명확한 변수명과 메서드명을 지어야 한다는 것도 알지만 늘 이만하면 됐겠지 하는 생각에 지나쳤던 지점들까지도 고민하고 파고들려고 노력했습니다. 어느 정도의 컨벤션을 지키면서 코드를 짜면서도 나만의 코드 스타일과 기준을 정립해가는 시간이 된 것 같습니다. 또한 접근 제어자, static으로 선언할지 하지 않을지 등과 같은 부분들은 기계적으로 코딩해오던 부분이었습니다. 부끄럽지만, 이 과정을 통해서 객체 지향적인 코드란 어떤 사고의 과정의 흐름으로 짜야 할지 왜 접근 제어자를 적절히 사용해야 하는지 이제서야 어느 정도 깨달은 것 같습니다. 저는 다음 지점들을 고려하며 코드를 짜고자 노력했습니다.

 

- 최대한 클린코드를 지향하며 짤 것

- 함부로 커밋하지 않을 것

- 하나의 메소드는 반드시 한 가지의 일만 담당하도록 할 것

- 메서드명을 허투로 짓지 않을 것

 

2. 고민하는 힘을 기르기

고민하는 힘을 기르는 것이 코딩에 있어 중요한 덕목이라는 생각이 들었습니다. 작은 것 하나 지나치지 않고 꾸준히, 동시에 '올바른' 방향으로 고민해 나가는 것이 필요하다고 생각했습니다. 코드 상의 로직 뿐만 아니라 언어로서도, 논리적으로도 말이 되는지를 계속해서 따져보고자 했습니다. 예를 들어 메서드 명을 지을 때나 클래스 명을 지을 때 전체적인 문제의 상황을 파악하며 여기서 계산기를 생성하는게 상황적으로 맞을지, 학생 자체의 클래스를 생성해서 정보를 저장하고 점수를 넘기는게 맞을지와 같은 상황적인 고려도 지속하고자 노력했습니다.

 

3. 클린코드는 이렇게 해야 하는구나

클린코드에 대한 막연한 생각은 있었지만 이는 아직 나의 영역이 아니라고 생각해 방치해두고 있었던 문제였습니다. 그러나, 클린코드 원칙을 지키면서 코드를 짜니 스스로도 코드를 짜면서 로직이 헷갈리지 않고 명확하게 보여 도움이 되었습니다. 클린코드의 필요성을 여실히 느낄 수 있는 기회였습니다.