이번 첫 과제를 시작하면서 기능 목록을 작성하고 바로 구현에 들어갔다. 구현을 끝내고 나니,
Player -> PlayerNumber -> Number
Computer -> ComputerNumber -> Number 이런 구조로 짜여졌다.
이러면 문제점이 뭐였냐면, 난 NumberComparator에서 Computer와 Player를 비교해야 하는데 ComputerNumber까지 접근해야해서 Computer와 ComputerNumber에서 메서드 중복이 일어났다.
이 부분을 너무 고치고 싶어서 하루동안 고민하고 구조를 다시 바꿔야 하나 생각했다. 생각을 비우고 다시 보니, Computer클래스의 역할이 없다는 것을 알았고 제거했다. 이렇게 수정하니 메서드 중복은 없어졌고, 불필요한 클래스도 없앨 수 있었다. 이게 맞는 방식인진 모르겠다
이러한 과정을 통해 하나 깨달은 게 있다. 처음 과제나 프로젝트를 시작할 때 기능목록도 중요하지만 설계 역시 중요하다는 것. 이 객체는 어떤 역할을 할 것이며 무슨 정보를 담고 있을지를 먼저 생각해 보는 습관을 들여야겠다. 다음 과제부터는 설계를 먼저 깔끔하게 한 후 코드를 짜봐야겠다!!
이건 다른 분의 코드를 리뷰하다가 깨달았다. 난 플레이어에게 입력받을 때마다 Player객체를 생성해서 값을 넣곤 했는데, 이러면 메모리에 영향을 주게 되어 악영향을 끼친단다.. 매번 생성하는 것이 아닌 입력을 받을 때 객체 내부를 초기화 하고 값을 다시 넣는 방법을 쓰는 것이 더 효율적일 것이다. 2주차 과제부터는 적극적으로 사용해 봐야겠다.
찾아보니 객체지향 프로그래밍 원칙에 '객체를 재사용하라'라는 말도 있더라.
내가 아직 다른 참가자분들보다 부족한 걸 알아서인지 디스코드 채널에서의 활동이 없었다. 코드리뷰를 할 때도 '내가 생각 한 방식이 맞을까?' , '이 리뷰를 보고 코웃음 치면 어떡하지?' 라는 생각이 많이 들어서 코멘트를 치려다 만 적도 많았다. 근데 이러면 내가 더 나아갈 수가 없다는 생각이 들었다. 2번처럼 코드리뷰를 받다 보면 내가 생각하지 못했던 부분을 알 때가 있을 것이다. 물론 코드리뷰를 하다가도 알 것이다. 정말 간절한 마음으로 참여하고 있고 떨어지더라도 나중에 되돌아 봤을 때 후회 없이 떨어지고 싶다. 혹시 내 생각이 틀렸더라도 다시 살펴보고 찾아보는 과정에서 얻는 것도 있을 것이기 때문에 적극적으로 참여해보고 싶다.
첫 구현을 시간을 들여가면서 해봤다. 리팩토링 과정을 줄이고 싶기도 하고 커밋을 깔끔하게 관리하고 싶기도 해서였다. 근데 다음날 보면 어색한 부분이 보였고 그 다음날도 그랬다. 마감 2시간 전까지 계속 고민했던 것 같다. 아무리 신중하게 짰어도 마음에 쏙 드는 코드는 짜기 힘들었던 것 같다. 그리고 코드리뷰를 받으면서 고쳐야 할 부분도 더욱 보이고 부족한 부분은 눈에 띄었다. 신중하게 짜되, 사소한 부분까지 완벽하게 짜려하지 말고 구현을 끝내고 리팩토링을 거치는 게 좋을 것 같다는 생각이 들었다.
과제를 정말 재밌게 했다. 처음 과제를 받곤 구현에 매달렸다. 이번 주는 정말 바쁘고 후회없이 산 것 같다. 과제도 당시엔 내가 만족할 만큼 리팩토링해서 제출했다. 다시 돌아보니 고칠 점이 많았지만, 내 프리코스 과정의 목적은 4주동안 부족한 부분을 채워서 1차 합격을 하는 것이다. 코드의 부족한 부분을 알아가는 과정 또한 과정, 경험이라 생각하고 다시 돌아봤을 때 후회없게 진행해보고 싶다.