1주차 과제는 문자열계산기였다.
https://github.com/bogeoung/java-calculator-7
GitHub - bogeoung/java-calculator-7
Contribute to bogeoung/java-calculator-7 development by creating an account on GitHub.
github.com
과제의 주된 목표는 기능 구현 목록을 작성하고, 그에 따라 git commit을 남기는 것이라고 이해했다.
따라서 이번주 나의 목표는 아래와 같았다.
🎯 이번 주 목표
1. 기능 구현 목록을 추후에 변경하는 일이 없도록 작성해보기
2. 돌아가는 코드를 만들기..
3. 기능 단위로 커밋하기
4. 코드 리뷰 참여하기
1. 기능 구현 목록 작성
기능 구현 목록을 작성하기에 앞서 과제 전문을 꼼꼼히 읽어보고 작성하면서 overflow를 고려하거나, 입력 문자가 1개만 들어올 수록 있게 고려한 점 등 나름 꼼꼼하게 작성했다고 생각했는데, 부족했던 점이 많았던 것 같다.
- 과제를 수행해 나가면서 필요없는 메소드가 있었다거나, 필요했지만 생각을 못했던 메소드들이 있었다.
-> 기능 구현 목록을 작성할 때 코드 구조를 충분히 고려하지 않고, 단순히 어떤 기능이 필요하겠구나와 같은 메소드 목록 위주로 생각했던 점이 문제였던 것 같다.
- 과제 이후 공유되는 테스트 케이스를 보면서 생각하지 못했던 테스트 케이스들이 진짜 무궁무진 했다는 것을 깨달았다.
-> 기능 구현 목록을 작성할 때 발생할 수 있는 예외 케이스들에 대해서도 충분히 고민이 필요했지 않았을까? 라는 생각이 들었다.
ex) 구분자가 공백인 경우, 구분자가 숫자인 경우, 소수 계산 허용 여부 등등..
구현 기능 목록을 작성하면서 신경을 썼던 점은 아래와 같다.
- 입력 숫자가 매우 크면 overflow가 발생하지 않을까?
-> String으로 저장해 관리하다가 MAX값 제한이 없는 BigInteger로 형변환 하여 계산한다. - `//`와 `\n`가 여러개 존재하는 것이 가능할까? | `//`와 `\n`가 문자열 제일 앞에 존재하지 않는다면?
-> 커스텀 구분자를 추가하는 문자 `//`와 `/n`는 단 한번, 문자열 시작에서만 존재할 수 있도록 기능 명세를 작성했다. - 커스텀 구분자를 여러개 추가하면?
-> 과제 페이지에서 `//`와 `/n` 사이에 위치하는 문자를 커스텀 구분자로 사용할 수 있다고 되어있어서, 단 하나의 문자만 커스텀 구분자만 추가할 수 있도록 기능 명세를 작성했다. - 구분자만 입력이 되고 숫자가 입력이 안되면?
-> 정상 입력으로 판단하기로 하였다.
2. 돌아가는 코드 만들기
사실 이번주 코드는 하나의 자바파일 안에 만들었다. 사실 디스코드에서 MVC패턴, TDD 등 다양한 이야기를 나누는 것을 보고 나도 저렇게 구현해봐야지! 라는 맘이 들었다. 그러기 위해서 MVC 패턴에 대해서 검색을 해보고, 어떻게 작성해야하는지 진지하게 고민을 하고 있었다. 그러던 중 객체가 뭔지는 아느냐는 질문에 제대로 질문을 못하겠는 나를 보고 "객체도 잘 모르는데 MVC 패턴은 어떻게 구현하게?"라는 말을 들었다. 따라서 이번 주 프로그래밍 목표는 아래와 같이 세웠다.
- 일단 돌아가는 코드를 작성해보자
- 코드의 가독성을 높여보자
- "객체지향의 사실과 오해" 책을 읽자
첫번째 목표에 따라 일단 하나의 자바파일에 모든 기능을 넣었다. 파일의 내용이 많은 것 같았지만...일단 나의 목표는 돌아가는 코드를 작성하는 것이였으니.. 그래도 일단 기능 구현을 완성한 후 동일한 기능을 수행하는 코드를 메소드로 빼고, 전역변수로 선언하고 등등 나름의 시도를 했다. 또 기능 구현을 완료한 후에도 해당 코드를 더욱 발전시킬 수 있는 방법에 대해서 생각해보았다.
두번째 목표, 가독성을 높이기 위해서는 변수명을 최대한 명확하게 하고, 메소드 명에는 해당 기능을 직관적으로 담으려고 했다.
그치만 수정 전 'addNum'이라는 메소드명을 보면 해당 메소드 안에서 합을 계산하고 무엇을 리턴하는지 알수가 없었다. 'getSumOfNumberTexts'로 메소드 명을 바꾸니 "숫자text들의 합을 리턴하는구나"라고 명확하게 이해할 수 있어서 메소드 명을 직관적으로 작성해야할 필요성에 대해 다시한번 깨달았다.
세번째 목표, 여전히 책을 읽고있는 중이지만 인상깊었던 구절을 몇개 적어보겠다.
훌륭한 객체지향 설계자가 되기 위해 거쳐야 할 첫 번째 도전은 코드를 담는 클래스의 관점에서 메세지를 주고받는 객체의 관점으로 사고의 중심을 전환하는 것이다. 중요한 것은 어떤 클래스가 필요한가가 아니라 어떤 객체들이 어떤 메세지를 주고받으며 협력하는가다. - p.38
객체의 자율성은 객체의 내부와 외부를 명확하게 구분하는 것으로부터 나온다.
...
객체의 외부에서는 접근이 허락된 수단을 통해서만 객체와 의사소통해야한다. 객체는 다른 객체가 무엇(what)을 수행하는지 알 수 있지만, 어떻게(how) 수행하는지에 대해 알 수 없다. - p.33
객체지향의 개념에 비유하면 바리스타로 전달된 커피 제조 요청이 메세지이고 커피를 제조하는 구체적인 방법이 메소드다. 커피 제조를 요청한 캐시어는 커피가 제조될 것이라고 기대하지만 커피를 제조하는 구체적인 방법에 관해서는 관여하지 않는다. 따라서 바리스타는 커피 제조라는 메시지에 응답하기 위해 자신만의 자율적인 방법에 따라 커피를 제조할 수 있다. - p.35
3. 기능단위로 커밋하기
"기능 단위로 커밋" 참 단어는 쉬운데 쉽지가 않았다. 왜지?라는 생각이 들어 고민해보는 중 "기능을 명확하게 분리를 안해서 그런게 아닐까?"라는 생각이 들어 기능 명세를 다시 한번 보게 되는 계기가 되었다.
이전까지 커밋 컨벤션은 나름 잘 지키고 있었다고 생각하였다.
하지만 우테코측에서 제공해준 git commit message convention 문서를 확인해보니, 이전까지의 나는 형태에 집중한 느낌? 정확히 어떤 기능을 추가했고, 어떤 것이 변경되었는지 등에 대해 알 수 없었다는 느낌이 들었다. 느낀점을 바탕으로 프리코스 1주차 커밋 메세지는 명확하지만 간결하게 작성해보고자 하였다.
4. 코드 리뷰하기
사실 12시 땡하자마자 코드 리뷰를 올릴려고 하였다. 그치만 올리는 다른 분들의 코드를 보니 내 코드는... 너무 부족한 것 같았다. 내가 내 코드에 대해서 피드백을 받은지언정, 나는 남의 코드에 피드백을 못해줄 것 같은 느낌이 너무 들었다. 그래서 이 글을 작성하고 있는 지금까지 코드 리뷰를 진행하지 못하고 있는데.. 디스코드에 포비님이 올려주신 메세지를 보고 안도를 느꼈다.
자바 문법도 잘 몰라서 구현 자체도 힘든데 OOP, TDD? 처음 들어보는 용어들 딱 내 이야기 였다.
해당 메세지에 위안을 받고 이번 주 내로는 꼭 리뷰를 진행하고자 한다.
마지막으로 원래 내 목표는 아니였지만 코드를 작성하면서 테스트 코드가 있는 것을 발견하고 나름의 테스트 코드를 작성하였다.
5. 테스트 코드 작성하기
테스트 코드도 부끄럽지만 처음 접해봤다. 하지만 이번 기회에 테스트 코드를 조금이라도 작성해보면서 내 코드의 문제점을 발견할 수 있었서 너무 인상깊었다. 테스트 코드 덕분에 이전 테스트의 결과가 후속 테스트의 영향을 미치고 있다는 사실을 발견하였다. 처음에는 foreach문을 테스트 코드에 추가하였고, 통과하는 것을 보고 수정 완료했다고 생각했다.
하지만 곧 foreach문은 테스트 코드에서만 존재하는데, 메인 코드의 메소드만 계속 실행된다면...? 초기화 안되서 문제가 발생하지 않을까? 라는 생각이 들었다. 이에 메인 코드에 매 실행마다 초기화하는 기능을 추가하였다. 테스트 코드를 통해 예상하지 못한 에러를 발견할 수 있었던 뜻깊은 시간이였다.
'회고' 카테고리의 다른 글
객체지향의 사실과 오해 (0) | 2024.12.13 |
---|---|
[우아한 테크코스] 프리코스 2주차 회고 (0) | 2024.10.30 |
[24.06.28] 99클럽 코테 스터디 40일차 TIL (0) | 2024.06.28 |
[24.06.27] 99클럽 코테 스터디 39일차 TIL - filter (0) | 2024.06.27 |
[24.06.26] 99클럽 코테 스터디 38일차 TIL - 다익스트라 (0) | 2024.06.26 |