우아한테크코스 1주차 후기

코드가 나오게 된 이유

처음에는 절차지향적으로 코드를 빠르게 완성시키는 것 만을 목적으로 코드를 작성했었습니다

7번까지 다 풀고 리팩토링을 하려고 여러가지 자료들을 찾아다니는 중에 이렇게 짜지 말라는 피드백을 받았습니다

전부 static 메소드로 분리하고, inner class를 쓰고, 그런 방식은 알고리즘 문제에 있어서는 좋은 방법이라도, 코스에 기준에는 맞지 않을 수 있다는 내용이었습니다

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

실제로 테크코스가 지키기를 권장하는 부분과는 살짝 거리가 있어보였습니다

 

그래서 최대한 객체지향적으로 책임을 나눠서 쪼개고, 여러 규칙을 지키는 것을 목적으로 했습니다

개인적으로 생각했던 목표

1. 최대한 객체지향적으로 코드를 완성해보자

2. 근거 있는 코드를 짜자

 

최대한 객체지향적으로 코드를 완성해보자

1. indent는 무조건 1로만 완성하자

2. else문은 사용하지 말자

3. 인스턴스 변수는 2개까지만 사용하자

4. 메서드는 10줄이 넘어가지 않도록 한다

5. 메서드의 인자는 2개까지만 사용한다

6. 책임을 2개 이상 갖는 클래스를 만들지 않는다

7. 단위 테스트를 만들어서 각각을 검증하자

8. solution함수에서 봤을 때 코드가 이해할 수 있어야 한다

 

이렇게 8가지 규칙을 무조건 지키려고 하다보니 다양한 것들을 배울 수 있었습니다

이 규칙을 지키려고 했던 과정을 바탕으로 문제에 내용들을 남기려고 합니다

 

규칙을 지키려 했을 때 기억에 남는 장점도 있고, 주의할 점도 있었습니다

1. indent를 1로만 한다

가장 어려웠던 조건이었습니다

for문에서 if문을 통한 return, break, continue 같은 쉬운 기능들을 아무것도 쓸 수 없었습니다

그렇기에 반복문 탈출 조건 하나하나를 만들어 내는 것도 쉽지 않았습니다

탈출 조건에 신경을 쓸 수 있었던 부분이 가장 기억에 남았습니다

 

2. else문은 사용하지 말자

1번 조건을 지키게 되면 2번 조건은 진짜 지키기 쉬웠습니다

모두 다 indent가 1이기에 그냥 else 대신 return만 써주면 끝이었습니다.

난이도는 쉬웠지만, 효과 자체는 컸습니다 

직관적으로 코드를 작성하는 것에 

3. 인스턴스 변수는 2개까지만 사용하자

2번재로 어려웠던 규칙이었습니다

여러 자료구조를 가지고 있고, 다양한 역할을 하는 solution같은 클래스를 만들어내면 달성하기 쉽지 않았습니다

생성자에 뭘 넣어야 하고, 메서드에 인자로 뭘 넣을지를 고민할 수 있던 부분이 좋았습니다

전에는 아무 생각 없이 생성자에 다 넣고, this.A=A; this.B=B;같은 코드를 작성해서 막 작성했던 코딩 스타일을 개선할 수 있었습니다

 

4. 메서드는 10줄이 넘어가지 않도록 한다

오히려 이 규칙은 신경 쓰지도 않았는데 그냥 달성됐던 부분이었습니다

indent를 1로 제한하고, 역할을 분리하는 것에 신경썼더니 달성되어서 오히려 신기했습니다

메서드가 짧아질 수 밖에 없었습니다

5. 메서드의 인자는 2개까지만 사용한다

2개로 제한하니 생각보다 쉬웠습니다

원래 규칙은 1개로 하려고 했었습니다 이때는 정말 어려웠었습니다

이때 자료구조상으로 map 같은 부분이 문제가 되었습니다

어디에 뭐를 넣는다는 부분을 물론 하나의 클래스로 만들어서 한다면 되지만 가독성을 헤친다는 생각을 하게 되었습니다

그래서 2개로 변경하니 제한이 생각보다 널널했습니다

 

6. 책임을 2개 이상 갖는 클래스를 만들지 않는다

처음 짜보는 코드 스타일이라서 이 부분도 정말 고민을 많이 했습니다

어디서부터 어디까지가 하나의 책임인지를 고민하게 되고, 외부에서 접근할 수 있는 메서드를 만드는 것에 대해 고민했습니다

이렇게 책임에 대해서 고민을 하다보니 메서드명, 클래스명을 충분히 생각할 수 있었습니다

데이터에 getter, setter를 작성하게 되면 그 코드가 문제가 되는 경우가 많아 getter, setter에 대한 규칙도 같이 고려할 수 있었습니다

 

7. 단위 테스트를 만들어서 각각을 검증하자(TDD도 약간?)

책임별로 나누고, 외부에서 각 클래스별로 접근할 수 있는 인터페이스 수가 별로 없었습니다

필요한 데이터도 명확했고, 나오는 결과도 정말 명확했기에 단위 테스트를 만드는 것이 쉬웠습니다

모든 것들을 테스트 할 수 있도록 만들어야 했기에 충분한 고민을 할 수 있어서 좋았습니다

책임을 명확하게 나누고, 그것에 해당하는 interface를 고려해야 먼저 테스트 코드를 작성할 수 있었기에 많은 도움이 됐습니다

 

8. solution함수에서 봤을 때 코드가 이해할 수 있어야 한다

클래스 명, 메서드 명, 변수명을 신경쓰고, 이 코드가 왜 여기에 들어가야 하는지를 계속 고민하게 되었습니다

인자로 넣을 때 생성자에 넣을 수도 있고, 메서드에 넣을 수도 있는데, 꼭 여기에 들어가야 하나? 라는 근거를 찾게 되었습니다

 

 

2. 근거 있는 코드를 짜자

1. 우아한테크코스에 이미 참여했던 분들을 찾자

실제로 기능 목록을 작성하기 위해서 고민할 때 이미 참여했던 분들이라면 어떻게 했을지를 고민했습니다

과거 참여자 최소 5명 이상의 레포에 있는 기능 목록을 보고, 블로그에 어떤 식으로 작성했는지 그 생각을 이해하려고 노력했습니다

과거 합격하셨던 분들이 작성했던 코드를 참고하기 위해서 그 분들이 했던 시도들, 하지 않았던 시도들을 확인했었습니다

이때 패키지를 추가해도 괜찮겠다는 결론을 얻을 수 있었습니다

 

 2. 주석을 달지 말자

1. 코드로 표현하지 못하는 정보를 제공하는 주석
2. 의도를 설명하는 주석
3. 결과를 경고하는 주석
4. 중요성을 강조하는 주석

이렇게 총 4가지의 목적을 가진 주석을 작성하게 된다면 좋지만

코드로 설명할 수 있는데 코드를 설명하는 주석

을 작성하게 된다면 오히려 가독성을 방해할 거 같아서 코드를 깔끔하게 짜는 것에 더 중점을 뒀습니다

3. 문제의 조건을 이해해보자

총 5가지 질문에 대한 답을 코치님들에게 듣고 싶었습니다

1. 패키지를 추가해도 되는지

• 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다.

실제로 적혀있던 README.md 에 내용이 문제가 됐습니다 패키지, 파일을 추가 하는 부분에는 제약이 전혀 없었지만, 혹시나 하는 부분이 있었기에 질문이 있었습니다

실제로 제출 과정에서 문제가 없었던 것으로 보아 패키지 추가는 문제가 되지 않았을 거라고 생각합니다

 

2. 테스트 코드를 추가해도 되는지

• 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다

이 부분 역시 위의 내용과 겹쳤습니다 

테스트코드를 포함했을 때 예기치 못한 오류로 인하여 실행에 실패하였습니다.

라는 내용이 나와서 저는 삭제하고 제출했지만, 이후에 테스트 코드를 포함해도 정상 제출이 된다는 것을 통해서 문제가 없었던 것으로 생각됩니다

 

3. 시작면과 마지막 면이 의미하는게 뭔지

이 제한 사항은 되게 애매했습니다 null,0인 진짜 표지를 의미하는 것인지, 1,2 인 부분을 의미하는 것인지를 확실히 할 수 없었습니다

전자라면 어차피 1~400 페이지를 통해서 검증이 될 부분인데 이 제약사항을 넣을 이유가 없어보였습니다

그래서 후자로 해석하고 문제를 풀어나갔습니다

 

4. 제한사항을 검증해야 하는지

잘못된 인자가 들어오면 IllegalArgumentException()을 발생시킬 수도 있고, return -1을 할 수도 있고, 아니면 무시할 수도 있는데 처리 방법도 나와있지 않았고, 처리 해야하는지도 확실하지 않았습니다

 

해서 손해보는 부분은 시간에 대한 배점이 있다면 이 부분을 손해볼 거 같았고

하면 안정성과 코드 퀄리티에 있어서 좋은 영향이 있을 것 같아서 작성했습니다

 

5. 중복된 문자를 제거하는데 순서가 있는지

이 부분은 슬랙에도 나왔던 질문입니다

"abbaa"가 들어오면

"abbaa"->"aaa"->""가 되는지

"abbaa"->"a"가 되는지에 대한 부분이었습니다

이때 전자였다면 논리적으로 문제가 될 부분이 있어서 후자로 생각하고 풀었습니다

"abbaab"가 있을 경우 앞에서 부터 제거하면 "aaab"->"b"가 되고, 뒤에서부터 제거하면 "abbb"->"a"가 됩니다

이 부분은 명확한 설명이 없었기에 확실하게 결정할 수 있는 후자로 작성할 수 있었습니다

 

후기

문제 자체의 난이도가 높지 않았기에 문제 외적인 부분을 어떻게 풀었는지, 목표가 뭐였는지에 대해 생각하며 발전할 수 있었습니다

단순한 기능의 작동을 목표로 하는 것보다는 가독성 좋은 코드, 깔끔한 코드, 추후에 변경하기 쉬운 코드에 대해서 고민하는 시간으로 되게 뜻깊었던 것 같습니다 

슬랙에서 올려주신 코드를 보고 정말 잘하는 사람이 많다는 점을 다시 느꼈고, 같이 프로그램을 진행해보고 싶다는 생각 역시 다시 한 번 갖게 되었습니다 

긴 글 읽어주셔서 감사합니다