[인프런 워밍업클럽 3기 백엔드 코드] 2주차 발자국

회고 - 미션

https://shore-judge-641.notion.site/Day7-1b34d1a0b2288042ad1fc21d2003a598?pvs=4

아무래도 이번 일주일 중 가장 기억에 남는 것은 리팩토링 실습 미션이다. 코드 리뷰를 받는 거기도 해서 최대한 잘 해보고 싶다는 생각에 열심히 하다보니 하루를 통째로 써서 리팩토링을 하게 됐다.

강의를 들을 때 강의 앞부분에서 어떤 내용을 가지고 리팩토링을 할지에 대해 설명을 들으면 혼자 한 번 생각나는 대로 코드도 좀 고쳐보고 그 다음에 강의를 듣던 식으로 해왔다. 그래서 그런식으로 생각나는 대로 하면 될 거 같았는데, 막상 혼자 해보려니까 쉽지 않았다.

코드를 보면 뭐가 잘못 되긴 했구나라는 생각이 들고, 좀 더 보다보면 이게 문제니까 어떤 식으로 고쳐야겠다는 생각은 든다. 하지만 이 다음부터 고치려하면 어떻게 곷쳐나가야 하는지가 좀 막막했다.

그럴때마다 하나의 리팩토링 과정에서는 하나만 진행해야 한다는 점을 마음속으로 되새기면서 하나씩 고쳐나가 보았다.

리팩토링을 진행하면서 현재 고치고 있는 부분외에도 거슬리는 부분이 들어와 다른 거 막 고치고 싶은 생각이 들때도 있었는데 그럴때마다 일단 지금 하는 것부터 고치자며 마음을 다 잡고 진행했다.

그리고 고치려는 게 너무 크게 느껴지면 조금씩 쪼개서 해보려고도 했다.

리팩토링에서 뿐만 아니라 뭔가를 구현해야 할 때 문제를 풀어야 할 때 등 개발을 배우고 나서 많은 상황에서 뭔가를 한번에 하려고 하면 안되고 되는 것부터, 할 수 있겠다고 생각 드는 것부터 해나가야 되는구나를 여러번 느끼게 되는 거 같다.

중간 점검 라이브

코드리뷰

계속 원래 의도와 다르게 동작해서 나를 힘들게 해서 그 부분이 있어서 이에 대해 질문드렸었다.

똑같은 내용을 복사해놓고 리팩토링을 진행하다보니 똑같은 이름의 다른 폴더에 있는 파일을 import를 해버려서 생긴 문제였다... 혹시 다른 폴더에 있는 걸 import하지 않았는지 확인을 하긴 했었는데 모든 파일을 확인했던게 아니라서 참..

실전에서는 같은 프로젝트내에 같은 이름을 갖는 파일을 만들 것 같지는 않으니 괜찮을 거 같긴 하지만 가장 기억에 남는다..ㅎㅎ

코드리뷰를 보면서 다른 분들의 코드를 보고 다른 분들의 생각, 사고의 흐름을 볼 수 있었다.

이때 코드 리뷰를 보면서 열린 마음으로 다른 사람의 코드를 볼 수 있어야 겠구나라는 생각을 했다. 우빈님은 본인의 원래 생각과 다르게 리팩토링을 한 코드를 보면서 충분한 이유가 있지 않을까 생각해보고 납득할 만한 이유가 있다는 생각이 들면 ok하셨다.

뭐 나도 다른 분들 코드를 보면서 틀렸다고 생각한 적이 있는 건 아니지만, 아무래도 내가 리팩토링하면서 코드를 작성할 때 다 나름의 고민을 하고 그 고민의 결론에 맞게 코드를 짰기 때문에 나와 다른 결론을 가지고 짠 코드를 보면 바로 받아들여지지는 않는 것 같다. 나와 다른 코드를 받아들이기 위해서는 한 단계 받아들이기 위한 사고를 거쳐야 한달까?

예를 들어 나는 A와 B중에 뭐가 더 나을까 고민해서 "음.. A가 좀 더 나은 듯!" 해서 A를 선택해서 코드를 작성했다면, B를 선택한 코드를 보면 바로 받아들여지기 보다는 "B보다는 A가 좀 더 낫다고 생각했는데?"라고 한 번 생각하고 나서 "음 다시 생각해보니까 A나 B나 뭐를 선택하든 뭐 비슷한가? 이 선택은 뭐를 확실히 더 낫다고 말하기는 애매한가?"라는 생각을 거쳐야 비로소 "B도 나쁘지 않군!", "B도 이렇게 하니까 괜찮네?"라는 결론을 내릴 수 있달까?

의도하지 않으면 나와 다른 코드를 쉽게 배척해버릴 수도 있겠다는 생각을 해서 열린 마음이 필요하다는 생각을 하게 됐다.

그리고 무엇보다 내가 고민조차 해보지 못한 지점에서 고민을 한 다른 분들의 코드를 보면서 저런 고민도 해볼 수 있겠다라는 생각을 했다.

강의내용

Readable Code

강의 중에서 Minesweeper의 필드였던 gameStatus를 GameBoard의 필드로 옮긴 내용이 있었다.

나는 처음에 이 부분이 바로 받아들여지지는 않았다. gameStatus라는 것은 말 그대로 Game에 대한 것이지 Board에 대한것이 아니라고 생각했기 때문이다. 그래서 어떤 근거로 gameStatus가 GameBoard의 필드가 될 수 있는 지에 대해 정리해 보았다.

gameStatus의 상태를 바꾸거나 확인하는 것은 Minesweeper에 있었지만 이건 단지 현재 gameStatus가 Minesweeper의 필드로 있어서 그런 것일 뿐이다. gameStauts가 바뀌는 것은 GameBoard에서 선택된 셀에 어떤 act(flag 또는 open)를 할때이다. GameBoard에서 어떤 셀에 act를 할때 그대로 이어서 GameBoard에서 gameStatus를 바꾸든가 확인을 해야지 그걸 굳이 GameBoard의 메서드를 호출한 Minesweeper에게 다시 gameStatus에 대해 조작이나 확인을 부탁하는 것이 부자연스럽다.
Minesweeper라는 이름때문에 게임자체를 의미하는 것 같지만 Minesweeper의 역할은 외부세계와의 접점이 되는 controller의 역할이다. 게임의 핵심적인 로직은 모두 GameBoard에 들어가있다. 그러니까 내가 생각한 Game 그 차제를 의미하는 거고 Minesweeper는 Game을 운영하는 것 뿐이다. 그래서 Game의 현재 이기고 지는 상태를 의미하는 gameStatus도 자연스레 GameBoard의 필드가 되어야 한다.

DFS를 재귀로 구현했을 때의 stack overflow의 위험이 있다. -> 재귀 구현은 조심해서 해야 됨

DFS가 안되면 BFS로 해야하나 싶긴 했는 데 둘 다 시간 공간 복잡도는 비슷한 걸로 기억한다.

DFS를 메서드 재귀호출이 아닌 스택을 활용해서 구현해서 stack overflow를 방지한다. -> 스택을 활용해서 DFS를 구현할 수도 있다는 것을 배웠다.

Practical Testing

테스트를 통해 원하는 또는 필요한 기능을 정의한다. -> 테스트가 스펙이 된다. -> 테스트는 문서다.

어떤 기능을 어떻게 사용하고 어떤 케이스에 어떤 결과가 나오는지에 대해 먼저 생각한다. -> 그렇다면 테스트를 먼저 작성해서 이로부터 기능을 구현해볼 수 있다. (TDD)